OpenSSO uses an identity repository to store user data such as users and groups. During OpenSSO Enterprise installation, you must specify which user data store you want to use. For example, you can use Sun Directory Server Enterprise Edition, Microsoft Active Directory, IBM Tivoli, or OpenDS.
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.
OpenSSO Enterprise Feature |
Sun Directory Server LDAPv3 |
OpenDS |
Microsoft Active Directory LDAPv3 |
IBM Tivoli Directory |
Generic LDAPv3 |
---|---|---|---|---|---|
User Data Storage |
Yes |
Yes |
Yes |
Yes |
No |
Configuration Data Storage |
Yes |
Yes |
No |
No |
No |
AMSDK (legacy) |
Yes |
No |
No |
No |
No |
LDAP Authentication |
Yes |
Yes |
Yes |
Yes |
Yes |
Membership Authentication |
Yes |
Yes |
No |
Yes |
No |
Active Directory Authentication |
Not Applicable |
Not Applicable |
Yes, with limitations |
Not Applicable |
Not Applicable |
Policy Subjects and Policy LDAP Filter Condition |
Yes |
Yes |
Yes |
Yes |
Yes |
Password Reset |
Yes |
Yes |
No |
No |
No |
Account Lockout |
Yes |
Yes |
No |
Yes |
No |
Cert Authentication |
Yes |
Yes |
Yes |
Yes |
Yes |
MSISDN Authentication |
Yes |
Yes |
Yes |
Yes |
Yes |
Data Store Authentication (through LDAPv3 user store configuration) |
Yes |
Yes |
Yes |
Yes |
Yes |
User creation with Password and Password Management |
Yes |
Yes |
No |
Yes |
Yes |
Password Policy |
Yes |
Limited support |
No |
No |
No |
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.
Feature |
Sun Directory Server LDAPv3 |
OpenDS |
Microsoft Active Directory LDAPv3 |
IBM Tivoli Directory |
AMSDK (Legacy) |
---|---|---|---|---|---|
Create User |
Yes |
Yes |
Yes* |
Yes |
Yes |
Modify User |
Yes |
Yes |
Yes* |
Yes |
Yes |
Delete User |
Yes |
Yes |
Yes* |
Yes |
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* |
Yes** |
Yes |
Modify Group |
Yes |
Yes |
Yes* |
Yes** |
Yes |
Delete Group |
Yes |
Yes |
Yes* |
Yes** |
Yes |
Evaluate Group for Membership |
Yes |
Yes |
Yes* |
Yes** |
Yes |
Federation Attributes |
Yes |
Yes |
Yes |
Yes |
Yes |
*Some limitations exist, or additional configuration is required. **See the limitations described in the next section. |
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
Auxilary 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 Access Manager 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.