OpenSSO Enterprise services need to interact with a number of different data stores. The following distinct repositories can be configured.
A configuration repository provides server and service specific data.
One or more identity repositories provide user profile information.
Authentication repositories provide authentication credentials to a particular module of the Authentication Service.
A common LDAP connection pooling facility allows efficient use of network resources. In the simplest demonstration environment, a single LDAP repository is sufficient for all data however, the typical production environment tends to separate configuration data from other data. The following sections contain more specific information.
The default configuration of OpenSSO Enterprise creates a branch in a fresh installation of a configuration data store for storing service configuration data and other information pertinent to the server's operation. OpenSSO Enterprise components and plug-ins access the configuration data and use it for various purposes including:
Accessing policy data for policy evaluation.
Finding location information for identity data stores and OpenSSO Enterprise services.
Retrieving authentication configuration information that define how users and groups authenticate.
Finding which partner servers can send trusted SAML assertions.
OpenSSO Enterprise supports Sun Java System Directory Server and the open source OpenDS as configuration data stores. Flat files (supported in previous versions of the product) are no longer supported but configuration data store failover is — using replication. Figure 2–14 illustrates how configuration data in the configuration data store is accessed.
Previous releases of Access Manager and Federation Manager stored product configuration data in a property file named AMConfig.properties that was installed local to the product instance directory. This file is deprecated for OpenSSO Enterprise on the server side although still supported for agents on the client side. See the Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide for more information.
Configuration data comprises the attributes and values in the OpenSSO Enterprise configuration services, as well as default OpenSSO Enterprise users like amadmin and anonymous. Following is a partial listing of the XML service files that contribute to the data. They can be found in the path-to-context-root/opensso/WEB-INF/classes directory.
The data in this node branch is private and is mentioned here for information purposes only.
AgentService.xml
amAdminConsole.xml
amAgent70.xml
amAuth.xml
amAuth-NT.xml
amAuthAD.xml
amAuthAnonymous.xml
amAuthCert.xml
amAuthConfig.xml
amAuthDataStore.xml
amAuthHTTPBasic.xml
amAuthJDBC.xml
amAuthLDAP.xml
amAuthMSISDN.xml
amAuthMembership.xml
amAuthNT.xml
amAuthRADIUS.xml
amAuthSafeWord-NT.xml
amAuthSafeWord.xml
amAuthSecurID.xml
amAuthWindowsDesktopSSO.xml
amClientData.xml
amClientDetection.xml
amConsoleConfig.xml
amDelegation.xml
amEntrySpecific.xml
amFilteredRole.xml
amG11NSettings.xml
amLogging.xml
amNaming.xml
amPasswordReset.xml
amPlatform.xml
amPolicy.xml
amPolicyConfig.xml
amRealmService.xml
amSession.xml
amUser.xml
amWebAgent.xml
idRepoEmbeddedOpenDS.xml
idRepoService.xml
identityLocaleService.xml
ums.xml
By default, the OpenSSO Enterprise configuration data is created and maintained in the configuration data store apart from any identity data. Although users can be created in the configuration data store this is only recommended for demonstrations and development environments.
For more information, see Configuration Data Store.
An identity repository is a data store where information about users and groups in an organization is stored. User profiles can contain data such as a first name, a last name, a phone number, group membership, and an e-mail address; an identity profile template is provided out-of-the-box but it can be modified to suit specific deployments.
Identity data stores are defined per realm. Because more than one identity data store can be configured per realm OpenSSO Enterprise can access the many profiles of one identity across multiple data repositories. Sun Java System Directory Server with OpenSSO Enterprise Schema, Microsoft Active Directory, IBM Tivoli Directory and the AMSDK data store are the currently supported identity repositories. Plug-ins can be developed to integrate other types of repositories (for example, a relational database). Figure 2–15 illustrates a OpenSSO Enterprise deployment where the identity data and the configuration data are kept in separate data stores.
The information in an identity repository is maintained by provisioning products separate from OpenSSO Enterprise. The supported provisioning product is Sun Java System Identity Manager.
OpenSSO Enterprise provides out-of-the-box plug-in support for some identity repositories. Each default plug-in configuration includes details about what operations are supported on the underlying data store. Once a realm is configured to use a plug-in, the framework can instantiate it and execute the operations on the appropriate identity repository. Each new plug-in developed must have a corresponding service management schema defining its configuration attributes. This schema would be integrated as a sub schema into idRepoService.xml, the service management file for the Identity Repository Service that controls the identity data stores available under a realm's Data Stores tab. The following sections contain information on the out-of-the-box plug-ins.
The Generic LDAPv3 identity repository plug-in can reside on an instance of any directory that complies with the LDAPv3 specifications. The underlying directory cannot make use of features that are not part of the LDAP version 3 specification, and no specific DIT structure can be assumed as LDAPv3 identity repositories are simply DIT branches that contain user and group entries. Each data store has a name that is unique among a realm's data store names, but not necessarily unique across all realms. The com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo class provides the default LDAPv3 identity repository implementation. There are also implementations for Active Directory and IBM Tivoli Directory
The Generic LDAPv3 identity repository plug-in was used to develop a default plug-in to write identity data to an instance of Microsoft® Active Directory®. The administration console provides a way to configure the directory but the schema needs to be loaded manually.
The Generic LDAPv3 identity repository plug-in was used to develop a default plug-in to write identity data to an instance of IBM Tivoli Directory®. The administration console provides a way to configure the directory but the schema needs to be loaded manually.
This repository resides in an instance of Sun Java System Directory Server and holds the identity data. This option is available during the initial configuration of OpenSSO Enterprise.
This repository resides in an instance of Sun Java System Directory Server and holds the configuration data when installing OpenSSO Enterprise in Legacy and Realm mode. This option must be manually configured.
The Access Manager Repository can reside only in Sun Java System Directory Server and is used with the Sun Directory Server With Access Manager Schema. During installation, the repository is created in the same instance of Sun Java System Directory Server that holds the configuration data. The Access Manager Repository Plug-in is designed to work with Sun Java System Directory Server as it makes use of features specific to the server including roles and class of service. It uses a DIT structure similar to that of previous versions of Access Manager.
This is no longer provided out of the box and many pieces are marked for deprecation. The Access Manager Repository is compatible with previous versions of Access Manager.
When you configure an instance of Access Manager in realm mode for the first time, the following occurs:
An Access Manager Repository is created under the top-level realm.
The Access Manager Repository is populated with internal Access Manager users.
The Java Enterprise System installer does not set up an Access Manager Repository when you configure an Access Manager instance in legacy mode. Legacy mode requires an identity repository that is mixed with the Access Manager information tree under a single directory suffix.
Authentication data contains authentication credentials for OpenSSO Enterprise users. An authentication data store is aligned with a particular authentication module, and might include:
RADIUS servers
SafeWord authentication servers
RSA ACE/Server systems (supports SecurID authentication)
LDAP directory servers
Identity data may include authentication credentials although authentication data is generally stored in a separate authentication repository. For more information, see Chapter 3, Configuring Authentication, in Sun OpenSSO Enterprise 8.0 Administration Guide.