In the previous chapters we have extensively called out the various identities including user, group, and role objects in the examples. All these identities must be stored in a backend data repository in order to be accessed by OpenSSO. It is worth remembering that this identity store is different from the configuration store (policy store).
The Identity Repository framework provides interfaces that will be used by OpenSSO services such as Authentication, Authorization, and Federation to manipulate identity configuration attributes along with certain service configuration values such as the agent profiles, even though the agent profiles are stored in the configuration store.
The Identity Repository framework has a utility class that provides interfaces to manage service configuration attributes of users, roles, and agents per realm. Additionally, it provides interfaces to manage generic attributes for identity objects such as realms, groups, roles, users, and agents.
There are Service Provider Interface (SPI) plugin interfaces in the Identity Repository framework to configure a new Identity Repository. Each SPI plugin would have a corresponding service XML schema file defining its configuration attributes as a subschema.
In this chapter, you will be able to learn the following topics:
- Identity Repository schema
- Types of identity stores supported
- Caching and notification
- Supported identity stores
- Multiple identity stores
- Extending schema for OpenLDAP Identity Repository schema
Like any other service, the Identity Repository service is also defined using an XML file named idRepoService.xml that can be found in<conf-dir>/config/xml. In this file one can define as many subschema as needed. By default, the following subschema names are defined:
- LDAPv3
- LDAPv3ForAMDS
- LDAPv3ForOpenDS
- LDAPv3ForTivoli
- LDAPv3ForAD
- LDAPv3ForADAM
- Files
- Database
However, not all of them are supported in the version that has been tested while writing this book. For instance the files, LDAPv3, and Database subschema are meant to be sample implementations. One can extend it for other databases, keeping this as an example. The rest of the sub configurations are all well tested and supported.
One of the Identity Repository types Access Manager Repository is missing from this definition, as it is a manual process to add it into the OpenSSO server. That is something which will be detailed later in this chapter. It is also called a legacy SDK plugin for OpenSSO. The Identity Repository framework requires support for logging service and session management to deliver its overall functionality.
In OpenSSO, multiple types of Identity Repository plugins are implemented including the following:
- LDAPv3Repo
- AgentsRepo
- InternalRepo/SpecialRepo
- FilesRepo
- AMSDKRepo
Unlike the Access Manager Repository plugin, these are available in a vanilla OpenSSO server. So customers can readily use it without requiring to perform any additional configuration steps.
LDAPv3Repo: Is the plugin that will be used by customers and the administrators quite frequently as the other types of plugin implementations are mostly meant to be used by OpenSSO internal services. This plugin forms the basis for building the configuration for supporting various LDAP servers including Microsoft Active Directory, Active Directory Application Mode (ADAM/LDS), IBM Tivoli Directory, OpenDS, and Oracle Directory Server Enterprise Edition. There are subschema defined for each of the recently mentioned LDAP servers in the IdRepo service schema as described in the beginning of this section. For more specific configuration details for each of the LDAP servers, refer to the specific section of this chapter.
AgentsRepo: Is a plugin that is used to manage the OpenSSO policy agents' profiles. Unlike the LDAPv3Repo, AgentsRepo uses the configuration repository to store the agent's configuration data including authentication information. Prior to the Agents 3.0 version, all agents accessing earlier versions of OpenSSO such as Access Manager 7.1, had most of the configuration data of the agents stored locally in the file system as plain text files. This imposed huge management problems for the customers to upgrade or change any configuration parameters as it required them to log in to each host where the agents are installed. Besides, the configuration of all agents prior to 3.0 was stored in the user identity store. In OpenSSO the agent's profiles and configurations are stored as part of the configuration Directory Information Tree (DIT).
The AgentsRepo is a hidden internal repository plugin, and at no point should it be visible to end users or administrators for modification.
SpecialRepo: In the predecessor of OpenSSO the administrative users were stored as part of the user identity store. So even when the configuration store is up and running administrators still cannot log in to the system unless the user identity store is up and running. This kind of limits the customer experience especially during pilot testing and troubleshooting scenarios. To overcome this, OpenSSO introduced a feature wherein all the core administrative users are stored as part of the configuration store in the IdRepo service. All the administrative and special user authentication by default uses this specialrepo framework. It may be possible to override this behavior by invoking module based authentication. SpecialRepo is used as a fallback repository to get authenticated to the OpenSSO server.
SpecialRepo is also a hidden internal repository plugin. At no point, should it be visible to end users or administrators for modification.
FilesRepo: Is no longer supported in the OpenSSO product. You can see the references of this in the source code but it cannot be configured to use flat files store for either configuration data or user identity data.
AMSDKRepo: This plugin has been made available to maintain the compatibility with the Sun Java System Access Manager versions. When this plugin is enabled the identity schema is defined using the DAI service as described in the ums.xml. This plugin will not be available in the vanilla OpenSSO server, the administrator has to perform certain manual steps to have this plugin available for use. In this plugin, identity management is tightly coupled with the Oracle Directory Server Enterprise Edition. It is generally useful in the co-existence scenario where OpenSSO needs to co-exist with Sun Access Manager. In this book wherever we refer to "Access Manager Repository plugin" it means refer to AMSDKRepo.
Besides this there is a sample implementation for the MySQL-based database repository available as part of the server default configuration. It works; however, it is not extensively tested for all the OpenSSO features. You can also refer to another discussion on the custom database repository implementation at this link: http://www.badgers-in-foil.co.uk/notes/installing_a_custom_opensso_identity_repository/.