Chapter 3 Simplifying OpenSSO Enterprise
This chapter contains information on the usability and manageability features of OpenSSO Enterprise. It includes the following sections:
Installation and Configuration
Previous versions of Sun Microsystems' access management server product were built for multiple hardware platforms, and different web containers. The complexity of this development process led to the release of separate platform and container patches. To alleviate this extraneous development, OpenSSO Enterprise is now available as a single ZIP file which can be downloaded, unzipped, and quickly deployed; there will be no separate installations for each hardware platform. The ZIP file will contain the full OpenSSO Enterprise web archive (WAR), layouts for the generation of other specific WARs, libraries, the Java API reference documentation, and samples. (Tools for use with OpenSSO Enterprise, including the command line interfaces and policy and authentication agents, can be downloaded separately.) Figure 3–1 illustrates the process for deployment, installation and configuration of a new OpenSSO Enterprise WAR and a patched WAR.
Figure 3–1 Customizing, Patching and Deploying the OpenSSO Enterprise WAR
Note –
When patched, a full patched version of the OpenSSO Enterprise WAR will be included in the download, assuring that there is always a single download to get the latest bits.
The intent of this new process is to allow the administrator to download OpenSSO Enterprise and deploy it on the container or platform of choice, using the web container's administration console or command line interfaces. After the initial launch of the deployed WAR, the user is directed to a JavaServer Page (JSP) called the Configurator that prompts for configuration parameters (including, but not limited to, the host name, port number, URI, and repositories), provides data validation for the parameter values to prevent errors, and eliminates post-installation configuration tasks. Once successfully configured, any further changes to the configuration data store must be made using the OpenSSO Enterprise console or command line interfaces.
Note –
When deploying OpenSSO Enterprise against an existing legacy installation, the Directory Management tab will be enabled in the new console.
For more information including a directory layout of the ZIP, see the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
Configuration Data Store
OpenSSO Enterprise has implemented an embedded configuration data store to replace the AMConfig.properties and serverconfig.xml files which had been the storage files for server configuration data. Previously, each instance of the server installed had separate configuration files but now when deploying more than one instance of OpenSSO Enterprise, all server configuration data is stored centrally, in one configuration data store per instance. After the OpenSSO Enterprise WAR is configured, a sub configuration is added under the Platform Service to store the data and a bootstrap file that contains the location of the configuration data store is created in the installation directory. Figure 3–2 illustrates how OpenSSO Enterprise is bootstrapped.
Figure 3–2 Bootstrapping OpenSSO Enterprise
Post installation, the configuration data can be reviewed and edited using the administration console or the ssoadm command line interface. For more information see the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide and the Sun OpenSSO Enterprise 8.0 Administration Guide.
Note –
OpenSSO Enterprise also supports an LDAPv3–based solution that uses an existing directory server for configuration data storage. This is configured during installation. Supported directories include Sun Java System Directory Server, Microsoft Active Directory, and IBM Tivoli Directory.
Centralized Agent Configuration
Policy agents function based on a set of configuration properties. Previously, these properties were stored in the AMAgent.properties file, residing on the same machine as the agent. With Centralized Agent Configuration, OpenSSO Enterprise moves most of the agent configuration properties to the configuration data store. Now agent profiles can be configured to store properties locally (on the machine to which the agent was deployed) or centrally (in the configuration data store), making this new function compatible with both older 2.x agents and newer 3.0 agents. Following is an explanation of the local and central agent configuration repositories.
-
Local agent configuration is supported for backward compatibility. Agent configuration data is stored in a property file named AgentConfiguration.properties that is stored on the agent machine. It is only used by agent profiles configured locally.
-
Centralized Agent Configuration stores agent configuration data in a centralized data store managed by OpenSSO Enterprise. When an agent starts up, it reads its bootstrapping file to initialize itself. AgentBootstrap.properties is stored on the agent machine and indicates the location from where the configuration properties need to be retrieved. It is used by agent profiles configured locally or centrally. Based on the repository setting in AgentBootstrap.properties, it retrieves the rest of its configuration properties. If the repository is local, it reads the agent configuration from a local file; if the repository is remote, it fetches its configuration from OpenSSO Enterprise.
Thus, Centralized Agent Configuration separates the agent configuration properties into two places: a bootstrapping file stored local to the agent and either a local (to the agent) or central (local to OpenSSO Enterprise) agent configuration data store. AgentBootstrap.properties is the bootstrapping file used by agent profiles configured locally or centrally. It is stored on the agent machine and indicates the local or central location from where the agent's configuration properties are retrieved. If the repository is local to the agent, it reads the configuration data from a local file; if the repository is remote, it fetches its configuration from OpenSSO Enterprise. Choosing Centralized Agent Configuration provides an agent administrator with the means to manage multiple agent configurations from a central place using either the OpenSSO Enterprise console or command line interface. Figure 3–3 illustrates how an agent retrieves bootstrapping and local configuration data, and configuration data from the configuration data store.
Figure 3–3 Retrieving Agent Configuration Data
An agent fetches its configuration properties periodically to determine if there have been any configuration changes. Any agent configuration changes made centrally are conveyed to the affected agents which will react accordingly based on the nature of the updated properties. If the properties affected are hot swappable, the agent can start using the new values without a restart of the underlying agent web container. Notification of the agent when configuration data changes and polling by the agent for configuration changes can be enabled. Agents can also receive notifications of session and policy changes.
Note –
A agent configuration data change notification does not contain the actual data; it is just a ping that, when received, tells the agent to make a call to OpenSSO Enterprise and reload the latest. Session and policy notifications, on the other hand, contain the actual data changes. Also, when using a load balancer, the notification is sent directly to the agent whose configuration has been changed. It does not go through the load balancer.
For more information see the Sun OpenSSO Enterprise 8.0 Administration Guide.
Common Tasks Wizard
OpenSSO Enterprise has implemented a Common Tasks tab that allows an administrators to create federation-based objects using console wizards. The wizards offer simplified provider configuration with metadata input using the URL http://host-machine.domain:8080/opensso/saml2/jsp/exportmetadata.jsp or a metadata file. The following things can be done using a Common Task wizard:
-
Create SAML v2 Providers They can be hosted or remote provider; and identity or service provider. To create them, you just need to provide some basic information about the providers.
-
Create Fedlet A Fedlet is a small ZIP file that can be given to a service provider to allow for immediate federation with an identity provider configured with OpenSSO Enterprise. It is ideal for an identity provider that needs to enable a service provider with no federation solution in place. The service provider simply adds the Fedlet to their application, deploys their application, and they are federation enabled. For more information, see The Fedlet.
-
Test Federation Connectivity This task validates your federation configuration. It will show if federation connections are being made successfully by identifying where the troubles, if any, are located.
-
Access Documentation This link opens the OpenSSO documentation page. View frequently asked questions, tips, product documentation, engineering documentation as well as links to the community blogs.
-
Register Your Product This link allows you to register your product with Sun Connection. You must have a Sun Online Account in order to complete the registration. If you do not already have one, you may request one as part of this process.
Figure 3–4 is a screen capture of the Common Tasks wizard.
Figure 3–4 The Common Tasks Wizard
For more information see the Sun OpenSSO Enterprise 8.0 Administration Guide.
Third Party Integration
OpenSSO Enterprise makes it easy to integrate with third-party software. Plug-ins and other tools have been developed to ease the integration of OpenSSO Enterprise and the following products.
For more information, see Sun OpenSSO Enterprise 8.0 Integration Guide.
Sun Java System Identity Manager
Sun Java System Identity Manager enables an enterprise to manage and audit access to accounts and resources as well as distribute the access management overhead. A OpenSSO Enterprise policy agent is deployed on the Identity Manager machine to regulate access to the Identity Manager server. By mapping Identity Manager objects to OpenSSO Enterprise users and resources, you may significantly increase operational efficiency. For use cases, a technical overview, installation and configuration procedures, architecture diagrams and process flows, see Chapter 1, Integrating Sun Identity Manager , in Sun OpenSSO Enterprise 8.0 Integration Guide.
Computer Associates SiteMinder
Computer Associates SiteMinder (originally developed by Netegrity) is one of the industry's first SSO products — used in a majority of legacy web SSO deployments to protect their intranet and external applications. OpenSSO Enterprise provides the tools for SSO integration with SiteMinder in both intranet and federated environments. They include a SiteMinder Agent and a OpenSSO Enterprise Authentication Module for SiteMinder. They can be found in the integrations/siteminder directory of the exploded opensso.war. For use cases, a technical overview, installation and configuration procedures, architecture diagrams and process flows, see Chapter 2, Integrating CA SiteMinder, in Sun OpenSSO Enterprise 8.0 Integration Guide.
Oracle Access Manager
Oracle Access Manager (originally developed by Oblix) is an SSO product with many of the same features as Sun OpenSSO Enterprise and Computer Associates SiteMinder. Oracle Access Manager can be deployed to protect both internal and external applications. OpenSSO Enterprise provides an Oracle Agent and a custom OpenSSO Enterprise Authentication Module for Oracle Access Manager. They can be found in the integrations/oracle directory of the exploded opensso.war. For use cases, a technical overview, installation and configuration procedures, architecture diagrams and process flows, see Chapter 3, Integrating Oracle Access Manager, in Sun OpenSSO Enterprise 8.0 Integration Guide.
- © 2010, Oracle Corporation and/or its affiliates