Identity Repository Service

The Identity Repository Service allows OpenSSO Enterprise to integrate an existing user data store (such as a corporate LDAP server) into the environment. The Identity Repository Service is able to access user profiles (as well as group and role assignments if supported) and is capable of spanning multiple repositories — even of different types. The Identity Repository Service is configured per realm under the Data Stores tab and its main functions are:

• To specify an identity repository that will store service configurations and attributes for users, groups and roles.

• To provide a list of identity repositories that can provide user attributes to the Policy Service and Federation Services frameworks.

• To combine the attributes obtained from different repositories.

• To provide interfaces to create, read, edit, and delete identity objects such as a realm, role, group, user, and agent.

• To map identity attributes using the Principal Name from the SSOToken object.

Access to the Identity Repository Service is provided by the com.sun.identity.idm Java package. The AMIdentityRepository class represents a realm that has one or more identity repositories configured and provides interfaces for searching, creating and deleting identities. The AMIdentity class represents an individual identity such as a user, group or role and provides interfaces to set, modify and delete identity attributes and assign and unassign services. IdRepo is an abstract class that contains the methods that need to be implemented by plug-ins when building new adapters for repositories not currently supported. The current implementation supports Sun Java System Directory Server, IBM Tivoli Directory and Microsoft Active Directory. The following diagram illustrates the design of the Identity Repository Service.

Figure 2–9 Identity Repository Service Design

Administrator roles are also defined by the Identity Repository Service. (This is currently available only when the Sun Directory Server With FAM Core Services schema is loaded.) For example, the Realm Administrator can access all data in all configured realms while the Subrealm Administrator can access data only within the specified realm. For more information, see Sun OpenSSO Enterprise 8.0 Deployment Planning Guide. For information on realm privileges, see Chapter 2, Organizing Data within Realms, in Sun OpenSSO Enterprise 8.0 Administration Guide.