OpenSSO Enterprise requires two data stores. During installation, you must specify the location of each data store. For detailed information, see Chapter 4, Configuring OpenSSO Enterprise Using the GUI Configurator, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
The configuration data store contains information about how users are authenticated, which resources users can access, and what information is available to applications after users are given access to resources. You can use the OpenSSO Enterprise configuration store that is automatically embedded in each OpenSSO Enterprise. Or you can use the Sun Directory Server configuration data store.
During OpenSSO Enterprise installation, you must specify which user data store you want to use.
Use this option when you want to store user data in the OpenSSO Enterprise user data store.
Use this option when you want to store user data in a data store such as Sun Java System Directory Server.
OpenSSO Enterprise uses an identity repository to store user data such as users and groups. You can use Sun Directory Server or a supported LDAPv3 compliant directory server as the identity repository. Use the tables in this section to help you determine which user data store meets your needs.
In the following table, a Policy Subject refers to the “who” part of the policy definition. The Policy Subject specifies the members or entities to which the policy applies. Policy Condition refers to the additional restrictions with which the policy applies. Examples are a specified window of time in a day, a specified IP address, or a specified authentication method.
Table 2–1 Supported Features for Various Directory Servers
OpenSSO Enterprise Feature |
Sun Directory Server LDAPv3 |
Microsoft Active Directory LDAPv3 |
IBM Tivoli Directory |
Generic LDAPv3 |
---|---|---|---|---|
User Data Storage |
Yes |
Yes |
Yes |
No |
Configuration Data Storage |
Yes |
No |
No |
No |
AMSDK (legacy) |
Yes |
No |
No |
No |
LDAP Authentication |
Yes |
Yes |
Yes |
Yes |
Membership Authentication |
Yes |
No |
No |
No |
AD Authentication |
Not Applicable |
Yes, with limitations |
Not Applicable |
Not Applicable |
Policy Subjects and Policy LDAP Filter Condition |
Yes |
Yes |
Yes |
Yes |
Password Reset |
Yes (with OpenSSO Enterprise SDK only) |
No |
No |
No |
Account Lockout |
Yes |
No |
No |
No |
Cert Authentication |
Yes |
Yes |
Yes |
Yes |
MSISDN Authentication |
Yes |
Yes |
Yes |
Yes |
Data Store Authentication (through LDAPv3 user store configuration) |
Yes |
Yes |
Yes |
Yes |
User creation with Password and Password Management |
Yes |
No |
Yes |
Yes |
The following table summarizes the user management operations supported through the IDRepo interface for various user data stores. An interface has been implemented specifically for Sun Directory Server and Microsoft Active Directory. The default implementation of this interface can be used and supported for any LDAPv3 user repository.
Table 2–2 Data Stores and Supported Operations
Feature |
Sun Directory Server LDAPv3 |
Microsoft Active Directory LDAPv3 |
IBM Tivoli Directory |
Generic LDAPv3 |
AMSDK (Legacy) |
---|---|---|---|---|---|
Create User |
Yes |
Yes* |
Yes |
No |
Yes |
Modify User |
Yes |
Yes* |
Yes |
No |
Yes |
Delete User |
Yes |
Yes* |
Yes |
No |
Yes |
Create Role |
Yes |
No |
No |
No |
Yes |
Modify Role |
Yes |
No |
No |
No |
Yes |
Delete Role |
Yes |
No |
No |
No |
Yes |
Assign Role |
Yes |
No |
No |
No |
Yes |
Evaluate Role for Membership |
Yes |
No |
No |
No |
Yes |
Create Group |
Yes |
Yes* |
Yes** |
No |
Yes |
Modify Group |
Yes |
Yes* |
Yes** |
No |
Yes |
Delete Group |
Yes |
Yes* |
Yes** |
No |
Yes |
Evaluate Group for Membership |
Yes |
Yes* |
Yes** |
No |
Yes |
Create Agent |
Yes |
No |
No |
No |
No |
Delete Agent |
Yes |
No |
No |
No |
No |
Modify Agent |
Yes |
No |
No |
No |
No |
Federation Attributes |
Yes |
Yes |
Yes |
No |
Yes |
*Some limitations exist, or additional configuration is required.
** See limitations in the next section “Additional Information About Using IBM Tivoli Directory Server Configured as the IDRepo Data Store.”
IBM Tivoli Directory Server's groups can be Static, Dynamic, and Nested. However, the OpenSSO Enterprise IDRepo framework (IDRepo DataStore) supports only the Static group. A Static group defines each member individually using either of the following:
Structural ObjectClass: groupofNames, groupOfUniqueNames, accessGroup, or accessRole
Auxiliary ObjectClass: ibm-staticgroup or ibm-globalAdminGroup
A Static group using the Structural ObjectClass groupOfNames and groupOfUniqueNames requires at least one member for ObjectClass groupOfNames or one uniquemember for groupOfUniqueNames. The Static group using the ObjectClass ibm-staticgroup does not have this requirement. The ObjectClass ibm-staticgroup is the only ObjectClass for which members are optional; all other object classes require at least one member.
OpenSSO Enterprise supports only one ObjectClass for groups. If you choose a type of group with an ObjectClass that requires at leas one member, then a user value must be present. This user will automatically be added to the group when a group is created. You can remove this user from the group afterward if you don't want this user to be a member of the group.
The value for the filter for searching of groups must the value specified by the chosen LDAP Group ObjectClass.
Most IBM Tivoli groups require at least one member when the group is created. When a group is created using the OpenSSO Enterprise console, no users are assigned to the group by default. Since IBM Tivoli has this restriction, when a group is created, the default user or member cn=auser1,dc=opensso,dc=java,dc=net is always automatically created and added to the group.
Account Lockout locks a user account based on the policies defined in the Directory Server.
For example, the user account can be locked when a specified number of login failures occurs.
The key difference between using a policy LDAP subject and the IDRepo interface subject is that policy LDAP subjects don't provide caching and notification updates. The AMIdentity Subject does provide caching an notification updates.
The policy LDAP subjects provide LDAP Organization, Role (if Sun Directory Server), Group, and User subjects to evaluate membership of a user and determine if the user belongs to one of these subjects. The same result can be obtained using the Identity Repository (IDRepo) interface subject named AMIdentity Subject. This interface subject was introduced when the product was named Access Manager 7.0. You can develop a policy subject for a JDBC user store. Authentication also supports the JDBC repository through the JDBC authentication module.
The IDRepo interface provides basic user management features for user, group, role, and OpenSSO Enterprise policy agent entities.
This interface enables OpenSSO Enterprise to support any user repository through the development of new plug-ins. Although limited to Sun Directory Server, Microsoft Active Directory, and IBM Tivoli Directory today, the IDRepo interface could potentially be expanded to include any LDAPv3 directory server such as OpenLDAP or Novel Directory for JDBC, flat files, and so forth.
Prior to Access Manager 7.0, user management was supported using Access Manager object classes and attributes in addition to using specific features from Sun Directory Server. This support still exists through the legacy AMSDK interface. But this support is deprecated and will be removed future releases.
The data change in the directory server must be propagated to OpenSSO Enterprise in a timely manner to ensure that OpenSSO Enterprise represents the correct data. The data in OpenSSO Enterprise is updated two ways. One way is by receiving notifications from the directory servers, and the other way is by polling the directory servers. For notification, directory servers typically provide persistent search notifications which OpenSSO Enterprise subscribes to. For polling, OpenSSO Enterprise provides configurable parameters to specify the intervals. OpenSSO Enterprise supports persistent search notifications with Sun Directory Server, Microsoft Active Directory, and IBM Tivoli Directory.