|
This article provides instructions for installing and configuring OpenDS to store user profiles, authentication data, and policies.
When configuring OpenDS as a user store for OpenSSO Express 7, keep the following in mind:
- OpenSSO Express 7 doesn't support the extensive password policy features provided by OpenDS.
- Only static groups are supported from the OpenSSO console for now.
Before You Begin
- Before following the instructions in this article, an OpenSSO Express 7 server must be already installed and configured on a supported web container.
- Creating a user data store using the OpenSSO Configurator is not supported in OpenSSO Express 7.
- Static groups with the member and uniquemember attributes have been tested and work as designed.
If you use these attributes, then you must add the groupOfNames object class to the User Data Store Configuration page.
- Testing is in progress for groups with other (virtual) attributes such as member, memberof, and ismemberof.
- The Referential Integrity plug-in must be enabled in the OpenDS.
The Referential Integrity plug-in ensures that when the groups are removed from the directory, all references in the users' entries are removed automatically. If the Referential Integrity plug-in is not enabled, you will see deleted groups displayed the users' profiles even after the group has been removed from the directory server.
To use OpenDS as the OpenSSO Express 7 user data store, complete these steps. Detailed instructions are provided in the following sections.
- Download and install OpenDS.
- Add the OpenSSO Express 7 schema and supporting OpenDS user management data to OpenDS..
- Configure OpenSSO Express 7 to Use OpenDS as the User Data Store.
To Download and Install OpenDS
- Download an OpenDS build from the following website: http://www.opends.org/promoted-builds/
- Follow the instructions in the OpenDS Installation Guide.
- Enable the OpenDS Referential Integrity plug-in. See Maintaining Referential Integrity in the OpenDS Installation Guide.
To Add the OpenSSO Express 7 Schema and Supporting OpenDS User Management Data to OpenDS
OpenSSO Express 7 leverages certain LDAPv3-compliant attributes. Additionally, other objectclasses and user attributes are required and must be added to OpenDS to take full advantage of OpenSSO's functionality.
User schema is contained in the following file: <opensso_configuration_directory>/am_remote_opends_schema.ldif
- To load the schema, run the following command:
ldapmodify -h <opends_host> -p <opends_port>
-D"RootDN" -w <RootDN_password> -c -f am_remote_opends_schema.ldif
- To load the configuration for the openssouser and ldapuser users, special users required by OpenSSO, do the following:
- Download the text contained in the file configure_opends_userstore.ldif to a local file named configure_opends_userstore.ldif on your system.
- Edit the the following:
- Change ROOT_SUFFIX to the root suffix of your user directory
- Change OPENSSO_USER_PASSWD to a password for the openssouser user
- Change LDAP_USER_PASSWD to a password for the ldapuser user
- Save the file.
- Run the following command:
ldapmodify -h <opends_host> -p <opends_port> -D"RootDN" -w <RootDN_password> -c
-a -f configure_opends_userstore.ldif
Configuring OpenSSO Express 7 to Use OpenDS as the User Data Store
Once you have configured OpenDS, you can configure OpenSSO Express 7 to work with OpenDS. Complete the following steps. Detailed instructions are provided in the following sections:
- Create a new LDAPv3-compliant user data store.
You can use the command-line interface or use the OpenSSO Express 7 Administration Console.
- Add OpenSSO Express 7 object classes and user attributes to the user data store.
- (Optional) Remove the OpenSSO Express 7 schema from OpenDS.
To Create a New LDAPv3-compliant User Data Store at the Command Line
The ssoadm command line tool must already be configured in the OpenSSO Express 7 server.
- Log into the OpenSSO Express 7 host.
- Download the text in the Example to a local file named datastore_opends_attrs.txt on you system. Modify the file as needed for your deployment. Be sure to replace the default OpenDS server name and port number with your OpenDS server name and port number. In the following example, the root suffix is dc=opensso,dc-Java,dc=net
com.iplanet.am.ldap.connection.delay.between.retries=1000
RequiredValueValidator=
sun-idrepo-ldapv3-config-active=Active
sun-idrepo-ldapv3-config-auth-naming-attr=uid
sun-idrepo-ldapv3-config-authenticatable-type=User
sun-idrepo-ldapv3-config-authid=cn=openssouser,ou=opensso adminusers,dc=opensso,dc=java,dc=net
sun-idrepo-ldapv3-config-authpw=amsecret12
sun-idrepo-ldapv3-config-cache-enabled=false
sun-idrepo-ldapv3-config-cache-size=10240
sun-idrepo-ldapv3-config-cache-ttl=600
sun-idrepo-ldapv3-config-connection_pool_max_size=10
sun-idrepo-ldapv3-config-connection_pool_min_size=1
sun-idrepo-ldapv3-config-createuser-attr-mapping=cn
sun-idrepo-ldapv3-config-createuser-attr-mapping=sn
sun-idrepo-ldapv3-config-dftgroupmember=
sun-idrepo-ldapv3-config-errorcodes=80
sun-idrepo-ldapv3-config-errorcodes=81
sun-idrepo-ldapv3-config-errorcodes=91
sun-idrepo-ldapv3-config-filterrole-attributes=
sun-idrepo-ldapv3-config-filterrole-objectclass=
sun-idrepo-ldapv3-config-group-attributes=cn
sun-idrepo-ldapv3-config-group-attributes=description
sun-idrepo-ldapv3-config-group-attributes=dn
sun-idrepo-ldapv3-config-group-attributes=iplanet-am-group-subscribable
sun-idrepo-ldapv3-config-group-attributes=objectclass
sun-idrepo-ldapv3-config-group-attributes=ou
sun-idrepo-ldapv3-config-group-attributes=uniqueMember
sun-idrepo-ldapv3-config-group-container-name=ou
sun-idrepo-ldapv3-config-group-container-value=groups
sun-idrepo-ldapv3-config-group-objectclass=groupofuniquenames
sun-idrepo-ldapv3-config-group-objectclass=iplanet-am-managed-group
sun-idrepo-ldapv3-config-group-objectclass=iplanet-am-managed-static-group
sun-idrepo-ldapv3-config-group-objectclass=top
sun-idrepo-ldapv3-config-groups-search-attribute=cn
sun-idrepo-ldapv3-config-groups-search-filter=(objectclass=groupOfUniqueNames)
sun-idrepo-ldapv3-config-idletimeout=0
sun-idrepo-ldapv3-config-inactive=Inactive
sun-idrepo-ldapv3-config-isactive=inetuserstatus
sun-idrepo-ldapv3-config-ldap-server=<hostName.domain:portNumber>
sun-idrepo-ldapv3-config-max-result=1000
sun-idrepo-ldapv3-config-memberof=
sun-idrepo-ldapv3-config-memberurl=memberUrl
sun-idrepo-ldapv3-config-nsrole=
sun-idrepo-ldapv3-config-nsroledn=
sun-idrepo-ldapv3-config-nsrolefilter=
sun-idrepo-ldapv3-config-numretires=3
sun-idrepo-ldapv3-config-organization_name=dc=opensso,dc=java,dc=net
sun-idrepo-ldapv3-config-people-container-name=ou
sun-idrepo-ldapv3-config-people-container-value=people
sun-idrepo-ldapv3-config-psearch-filter=(objectclass=*)
sun-idrepo-ldapv3-config-psearch-scope=SCOPE_SUB
sun-idrepo-ldapv3-config-psearchbase=dc=opensso,dc=java,dc=net
sun-idrepo-ldapv3-config-referrals=true
sun-idrepo-ldapv3-config-search-scope=SCOPE_ONE
sun-idrepo-ldapv3-config-service-attributes=
sun-idrepo-ldapv3-config-ssl-enabled=false
sun-idrepo-ldapv3-config-time-limit=10
sun-idrepo-ldapv3-config-uniquemember=uniqueMember
sun-idrepo-ldapv3-config-user-attributes=adminRole
sun-idrepo-ldapv3-config-user-attributes=authorityRevocationList
sun-idrepo-ldapv3-config-user-attributes=caCertificate
sun-idrepo-ldapv3-config-user-attributes=cn
sun-idrepo-ldapv3-config-user-attributes=distinguishedName
sun-idrepo-ldapv3-config-user-attributes=dn
sun-idrepo-ldapv3-config-user-attributes=employeeNumber
sun-idrepo-ldapv3-config-user-attributes=facsimileTelephoneNumber
sun-idrepo-ldapv3-config-user-attributes=givenName
sun-idrepo-ldapv3-config-user-attributes=homePhone
sun-idrepo-ldapv3-config-user-attributes=homePostalAddress
sun-idrepo-ldapv3-config-user-attributes=inetUserHttpURL
sun-idrepo-ldapv3-config-user-attributes=inetUserStatus
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-auth-configuration
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-add-session-listener-on-all-sessions
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-destroy-sessions
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-get-valid-sessions
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-max-caching-time
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-max-idle-time
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-max-session-time
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-quota-limit
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-service-status
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-static-group-dn
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-account-life
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-admin-start-dn
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-alias-list
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-auth-config
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-auth-modules
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-failure-url
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-federation-info
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-federation-info-key
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-login-status
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-password-reset-force-reset
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-password-reset-options
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-password-reset-question-answer
sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-success-url
sun-idrepo-ldapv3-config-user-attributes=mail
sun-idrepo-ldapv3-config-user-attributes=manager
sun-idrepo-ldapv3-config-user-attributes=memberOf
sun-idrepo-ldapv3-config-user-attributes=mobile
sun-idrepo-ldapv3-config-user-attributes=ds-pwp-account-disabled
sun-idrepo-ldapv3-config-user-attributes=objectClass
sun-idrepo-ldapv3-config-user-attributes=pager
sun-idrepo-ldapv3-config-user-attributes=postalAddress
sun-idrepo-ldapv3-config-user-attributes=postofficebox
sun-idrepo-ldapv3-config-user-attributes=preferredlanguage
sun-idrepo-ldapv3-config-user-attributes=preferredLocale
sun-idrepo-ldapv3-config-user-attributes=preferredtimezone
sun-idrepo-ldapv3-config-user-attributes=secretary
sun-idrepo-ldapv3-config-user-attributes=sn
sun-idrepo-ldapv3-config-user-attributes=street
sun-idrepo-ldapv3-config-user-attributes=sun-fm-saml2-nameid-info
sun-idrepo-ldapv3-config-user-attributes=sun-fm-saml2-nameid-infokey
sun-idrepo-ldapv3-config-user-attributes=sunAMAuthInvalidAttemptsData
sun-idrepo-ldapv3-config-user-attributes=sunIdentityMSISDNNumber
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerDiscoEntries
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPAddressCard
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNameAltCN
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNameCN
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNameFN
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNameMN
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNamePT
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNameSN
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPDemographicsAge
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPDemographicsBirthDay
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPDemographicsDisplayLanguage
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPDemographicsLanguage
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPDemographicsTimeZone
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPEmergencyContact
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPEmploymentIdentityAltO
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPEmploymentIdentityJobTitle
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPEmploymentIdentityOrg
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPEncryPTKey
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPFacadegreetmesound
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPFacadeGreetSound
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPFacadeMugShot
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPFacadeNamePronounced
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPFacadeWebSite
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPInformalName
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityAltIdType
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityAltIdValue
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityDOB
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityGender
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityLegalName
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityMaritalStatus
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityVATIdType
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityVATIdValue
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPMsgContact
sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPSignKey
sun-idrepo-ldapv3-config-user-attributes=telephoneNumber
sun-idrepo-ldapv3-config-user-attributes=uid
sun-idrepo-ldapv3-config-user-attributes=userCertificate
sun-idrepo-ldapv3-config-user-attributes=userPassword
sun-idrepo-ldapv3-config-user-objectclass=inetadmin
sun-idrepo-ldapv3-config-user-objectclass=inetorgperson
sun-idrepo-ldapv3-config-user-objectclass=inetUser
sun-idrepo-ldapv3-config-user-objectclass=iplanet-am-managed-person
sun-idrepo-ldapv3-config-user-objectclass=iplanet-am-user-service
sun-idrepo-ldapv3-config-user-objectclass=iPlanetPreferences
sun-idrepo-ldapv3-config-user-objectclass=organizationalPerson
sun-idrepo-ldapv3-config-user-objectclass=person
sun-idrepo-ldapv3-config-user-objectclass=sunFederationManagerDataStore
sun-idrepo-ldapv3-config-user-objectclass=sunFMSAML2NameIdentifier
sun-idrepo-ldapv3-config-user-objectclass=sunIdentityServerLibertyPPService
sun-idrepo-ldapv3-config-user-objectclass=top
sun-idrepo-ldapv3-config-users-search-attribute=uid
sun-idrepo-ldapv3-config-users-search-filter=(objectclass=inetorgperson)
sun-idrepo-ldapv3-ldapv3Generic=
sunIdRepoAttributeMapping=
sunIdRepoClass=com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo
sunIdRepoSupportedOperations=group=read,create,edit,delete
sunIdRepoSupportedOperations=realm=read,create,edit,delete,service
sunIdRepoSupportedOperations=user=read,create,edit,delete,service
- Run the following command:
ssoadm create-datastore -m "OpenDS User Store" -t "LDAPv3" -D datastore_opends_attrs.txt
-u amadmin -f /tmp/.pass_of_amadmin -e /
The file .pass_of_amadmin contains the amadmin user's password in plain text.
- (Optional)To use this server as the LDAP authentication source:
- Configure the LDAP authentication instance with the bind user cn=ldapuser.
- Configure the policy configuration service with the bind user cn=ldapuser.
To Create a New LDAPv3-compliant User Data Store Using the OpenSSO Express 7 Administration Console
- Log in to the OpenSSO Express 7 administration console.
- Click the Access tab, an then Top-level Realm > Data Stores.
- On the Data Stores tab, click the Generic LDAP v3 user data store.
- On the Generic LDAP v3 data store page, add the LDAP User object classes and attributes.
- If they do not already exist, add the following LDAP User Object Classes:
inetadmin
inetorgperson
inetUser
iplanet-am-managed-person
iplanet-am-user-service
iPlanetPreferences
organizationalPerson
person
sunFederationManagerDataStore
sunFMSAML2NameIdentifier
sunIdentityServerLibertyPPService
top
- If they do not already exist, add the following LDAP User Attributes:
adminRole
authorityRevocationList
caCertificate
cn
distinguishedName
dn
ds-pwp-account-disabled
employeeNumber
facsimileTelephoneNumber
givenName
homePhone
homePostalAddress
inetUserHttpURL
inetUserStatus
iplanet-am-auth-configuration
iplanet-am-session-add-session-listener-on-all-sessions
iplanet-am-session-destroy-sessions
iplanet-am-session-get-valid-sessions
iplanet-am-session-max-caching-time
iplanet-am-session-max-idle-time
iplanet-am-session-max-session-time
iplanet-am-session-quota-limit
iplanet-am-session-service-status
iplanet-am-static-group-dn
iplanet-am-user-account-life
iplanet-am-user-admin-start-dn
iplanet-am-user-alias-list
iplanet-am-user-auth-config
iplanet-am-user-auth-modules
iplanet-am-user-failure-url
iplanet-am-user-federation-info
iplanet-am-user-federation-info-key
iplanet-am-user-login-status
iplanet-am-user-password-reset-force-reset
iplanet-am-user-password-reset-options
iplanet-am-user-password-reset-question-answer
iplanet-am-user-success-url
mail
manager
memberOf
mobile
objectClass
pager
postalAddress
postofficebox
preferredlanguage
preferredLocale
preferredtimezone
secretary
sn
street
sunAMAuthInvalidAttemptsData
sun-fm-saml2-nameid-info
sun-fm-saml2-nameid-infokey
sunIdentityMSISDNNumber
sunIdentityServerDiscoEntries
sunIdentityServerPPAddressCard
sunIdentityServerPPCommonNameAltCN
sunIdentityServerPPCommonNameCN
sunIdentityServerPPCommonNameFN
sunIdentityServerPPCommonNameMN
sunIdentityServerPPCommonNamePT
sunIdentityServerPPCommonNameSN
sunIdentityServerPPDemographicsAge
sunIdentityServerPPDemographicsBirthDay
sunIdentityServerPPDemographicsDisplayLanguage
sunIdentityServerPPDemographicsLanguage
sunIdentityServerPPDemographicsTimeZone
sunIdentityServerPPEmergencyContact
sunIdentityServerPPEmploymentIdentityAltO
sunIdentityServerPPEmploymentIdentityJobTitle
sunIdentityServerPPEmploymentIdentityOrg
sunIdentityServerPPEncryPTKey
sunIdentityServerPPFacadegreetmesound
sunIdentityServerPPFacadeGreetSound
sunIdentityServerPPFacadeMugShot
sunIdentityServerPPFacadeNamePronounced
sunIdentityServerPPFacadeWebSite
sunIdentityServerPPInformalName
sunIdentityServerPPLegalIdentityAltIdType
sunIdentityServerPPLegalIdentityAltIdValue
sunIdentityServerPPLegalIdentityDOB
sunIdentityServerPPLegalIdentityGender
sunIdentityServerPPLegalIdentityLegalName
sunIdentityServerPPLegalIdentityMaritalStatus
sunIdentityServerPPLegalIdentityVATIdType
sunIdentityServerPPLegalIdentityVATIdValue
sunIdentityServerPPMsgContact
sunIdentityServerPPSignKey
telephoneNumber
uid
userCertificate
userPassword
- Click Save.
To Remove the OpenSSO Express 7 schema from OpenDS
At some point if you want to remove the schema you added to OpenDS in these instructions, log into the OpenDS host and run the following command
ldapmodify -h <opends-host> -p <opends_port> -D"cn=directory manager" -w <password> -c
-f remove_am_remote_opends_schema.ldif
This will remove the OpenSSO Express 7 user schema. See https://opensso.dev.java.net/source/browse/opensso/products/amserver/war/ldif/remove_am_remote_opends_schema.ldif?rev=1.1&view=log
Troubleshooting
When an administrator tries to change a user's password using the OpenSSO Express 7 console or CLI or using the ldap-modifyutility, if the following message is displayed in the OpenDS access log: "You do not have sufficient privileges to reset user passwords, " then the password-reset privilege is not configured.
In OpenDS, you must add the password-reset privilege and assign it to an administrator. In the following example, the administrator is named openssouser. This privilege enables the administrator to reset the passwords of other users in the directory. The password-reset privilege works in association with the OpenDS ACIs that are set in the target.
About the OpenSSO Express 7 User Data Store
OpenSSO Express 7 uses an identity repository to store user data such as users and groups. During OpenSSO Express 7 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.
Table 2-1 Supported Features for Various Directory Servers
| OpenSSO Express 7 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.
Table 2-2 Data Stores and Supported Operations
| 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 limitations in the next section "Additional Information About Using IBM Tivoli Directory Server Configured as the IDRepo Data Store."
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 Express 7 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 Express 7 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 Express 7 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.
Additional Information for Determining Which User Data Store to Use
- 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 Express 7 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.
|
|
Comments (10)
Jun 08
timothywebster says:
I am a little confused. My understanding is that opensso's embedded id repositor...I am a little confused. My understanding is that opensso's embedded id repository is opends but is not recommended for production environments. What are the problems that are solved by using a standalone instance of opends, and how is the opends configuration described in this article different from the configuration of the embedded opends instance?
Jun 08
ginac says:
The embedded OpenDS is primarily meant for storing the OpenSSO configuration and...The embedded OpenDS is primarily meant for storing the OpenSSO configuration and policy data, and not for storing user data. If you want to use OpenDS in production, then using an external or standalone OpenDS would be a more scalable and performance-efficient option.
Jun 09
timothywebster says:
I understand that conceptually, but I wondered what specific differences I shoul...I understand that conceptually, but I wondered what specific differences I should expect between standalone and embedded OpenDS. For example, maybe the embedded OpenDS can't be set up in a load balanced or fault tolerant configuration? Is that the kind of thing that makes standalone more scalable and performance efficient?
Jun 15
metadaddy says:
One big difference is that the embedded instance of OpenDS shares a Java virtual...One big difference is that the embedded instance of OpenDS shares a Java virtual machine with OpenSSO. This places limits on its scalability and flexibility of deployment compared with a standalone OpenDS.
A standalone instance of OpenDS:
Jun 22
ahnjoan says:
I've followed the above instructions and notice that after completion, the attri...I've followed the above instructions and notice that after completion, the attribute "memberof" is only added to the embedded data store when adding a user to a group and not to the new user data store. I also noticed that the "Admin" group is no longer viewable within the console. Would appreciate anyone's thoughts on these two issues.
Thanks
Ahnjoan
Jul 02
ginac says:
Ahnjoan, I forwarded your questions (posted elsewhere) to one of our QA staff. ...Ahnjoan,
I forwarded your questions (posted elsewhere) to one of our QA staff. See his comments inline:
After configuring an additional user store...
1. The attribute "memberof" is only written to the users entry in the
embedded user store and not to a users entry in the new user store.
> If this can be modified, where do you modify this behavior?
if it is writing to the embedded store then the config look right, just delete the embedded user store and try with only the external user store
2. Each user in the new user store is given inetadmin objectclass, I
can't say this is wrong but it seems to me "plain" users shouldn't
have the word "admin" in any attribute by default. Did I do something
wrong to make this happen?
> It is correct, not sure why you are saying that inetadmin obj class cannot be there in the user entry, but if you want to manage users from opensso console then the inetadmin obj class is must as we rely on the inetuserstatus attribute
3. The default group "Admin" no longer shows up in the console. This
is the group that amadmin belongs to and its defined in the embedded
store under services but can no longer be viewed under groups using
the console.
> Look at the groups search filter in the datastore config page , may be it has the wrong filter
4. It seems that everything added to the new user store also gets
added to the embedded store. I though the reason for having a
separate data store for the users was to alleviate some performance
impact of having the users in the embedded directory. If that is the
purpose, is this the expected behaviour or did I configure something
incorrectly?
> The behaviour is correct, if you dont want the user to be added in a user store just remove the permission user=write from the datastore config page
Jun 24
VnextKris says:
Is there any particular reason that the following operations are not supported u...Is there any particular reason that the following operations are not supported using OpenDS as the data store:
Create Role
Modify Role
Delete Role
Assign Role
Evaluate Role for Membership
Surely these are fairly key requirements that won't be met by the embedded OpenDS store?
I'd like to use a seperate installation of OpenDS as our directory, but with these features lacking I'm wondering whether thats a good idea or not?
Jun 25
inthanga says:
OpenDS does not directly support Roles, however there is a way to achieve the sa...OpenDS does not directly support Roles, however there is a way to achieve the same functionality, you need to configure the OpenDS using this https://www.opends.org/wiki/page/SimulatingDSEERolesInOpenDS instruction. This is beyond the scope of OpenSSO.
Jul 22
ahnjoan says:
Ginac - Thank you very much for forwarding on my questions and posting the answe...Ginac - Thank you very much for forwarding on my questions and posting the answers. I'm having a very hard time getting this to work so I've removed all opensso and opends software from our development environment and followed the directions exactly as they are written. From this i have few additional questions.
The following questions apply to the section titled "To Create a New LDAPv3-compliant User Data Store at the Command Line" in the directions.
1. Item number four, sub item a
Is this modification completed to the LDAP "module" on the "Authentication" tab?
If so should the instructions include removing the embedded directory value from the "current values" of the "Primary LDAP Server" and adding the new directory in its place?
Is there a way to do this on the command line?
2. Item number four, sub item b
Is this modification completed to the policy configuration service on the "Services" tab?
If so should the instructions include removing the embedded directory value from the "current values" of the "Primary LDAP Server" and adding the new directory in its place?
Is there a way to do this on the command line?
Assuming the above questions are all answered in the affirmative I have the following problems.
1. Users added to the new OpenDS directory do not show up in the subjects->user tab.
2. New users created in the OpenSSO GUI are only created in the embedded directory (before I remove the embedded data store from the gui)
3. Attempting to remove the embedded store in the GUI causes the following failures
When attempting to create a user in the GUI or attempting to access the Privileges tab results in "Plug-in com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo encountered an ldap exception. LDAP Error 49: The credentials presented to the server for authentication are not valid."
Clicking on a user in the Subjects->Users tab, and then browsing a single users group tab results in the following error. "There is no information to display for this entry."
I'm assuming I just have not completed a step that the directions take for granted that I should have. I have started this process from beginning to end three times in an orderly (scripted as much as possible to eliminate error on my end) and get the same results each time. NOTHING other than what is in the directions has been done.
Thanks
Ahnjoan
Jul 22
ahnjoan says:
Please disregard the above post. If you happen to be experiencing the same thin...Please disregard the above post. If you happen to be experiencing the same things I was please check the following.
1. The full DN is entered for ldapuser in the authentication LDAP module "DN for Root User Bind" entry
2. The full DN is entered for ldapuser in the policy configuration service "LDAP Bind DN" entry
Thanks to Indira Thangasamy for answering this same issue that Krishna Kumar posted. Apologies for not finding it on the mailing list before I posted here.
Thanks
Ahnjoan