1.0 Install and Configure the OpenDS

You can download the latest version of OpenDS at this location. Here are simple few steps to download and configure the OpenDS

The above sequence of commands will download and setup the OpenDS server with suffix  dc=opensso,dc=java,dc=net (-a option creates this suffix), find more detailed instructions on how to setup OpenDS at this url https://opends.dev.java.net/public/docs/user-docs/QuickSetup-guide.html

2.0 Preparing OpenDS to be used as OpenSSO user store

Before adding OpenDS as the user store to the OpenSSO, you need to prepare the OpenDS with appropriate schema and other configuration users with proper privileges.

2.1 Adding the basic configuration users

OpenDS can be used as a profile,authentication and policy store, for authentication and policy subjects read only permissions are enough. For profile read and write permissions are required. 

There will be two users created under the root suffix
  • cn=openssouser,ou=opensso adminusers,dc=opensso,dc=java,dc=net – this user has all permissions under the suffix
  • cn=ldapuser,ou=opensso adminusers,dc=opensso,dc=java,dc=net – this user will have only read access to the suffix

dn: ou=people,dc=opensso,dc=java,dc=net
objectClass: top
objectClass: organizationalUnit

dn: ou=groups,dc=opensso,dc=java,dc=net
objectClass: top
objectClass: organizationalUnit

dn: ou=opensso adminusers,dc=opensso,dc=java,dc=net
objectClass: top
objectClass: organizationalUnit

dn: cn=openssouser,ou=opensso adminusers,dc=opensso,dc=java,dc=net
objectclass: inetuser
objectclass: organizationalperson
objectclass: person
objectclass: top
cn: openssouser
sn: openssouser
userPassword: amsecret12

dn: cn=ldapuser,ou=opensso adminusers,dc=opensso,dc=java,dc=net
objectclass: inetuser
objectclass: organizationalperson
objectclass: person
objectclass: top
cn: ldapuser
sn: ldapuser
userPassword: secret123

2.2 Adding the privilege to enable password reset for the other users

 In the OpenDS there is a special privilege that needs to be assigned for an user to reset password of other users, this works in association with the ACIs that are set in the target.  We need to add the password-reset privilege to the openssouser

dn: cn=openssouser,ou=opensso adminusers,dc=opensso,dc=java,dc=net
changetype: modify
add: ds-privilege-name
ds-privilege-name: password-reset

Adding the above  privilege enables the ‘openssouser’ to modify other users’ password in the directory with out this privilege, you would see "You do not have sufficient privileges to reset user passwords" message in the OpenDS access log when you try to change the password from opensso console or from any ldap tool such as ldapmodify.

Note: You dont need to add the above right now, as I have put all of these in a separate file and loading in section 3 of this document. 

2.3  Adding the Access Control Instructions(ACIs)

There are four ACIs are required to make the OpenDS work with OpenSSO as user store.

2.3.1 ACI to allow read and search permissions for the ldapuser

This ‘ldapuser’  will be used as the BIND DN in the Policy Configuration and the LDAP authentication instances configurations.

aci: (target="ldap:///dc=opensso,dc=java,dc=net")(targetattr="\*")(version 3.0; a
 cl "OpenSSO Authn bind ldap user rights"; allow (read,search) userdn = "ldap:///
 cn=ldapuser,ou=opensso adminusers,dc=opensso,dc=java,dc=net"; )

2.3.2 ACI to allow all permissions under the root suffix

This user will be used as the configuration DN in the datastore configuration page, this user should have all the permissions to the users entries including password change for other users. This user should be used as the bind DN in the Passwordreset service as this user has the special privilege to reset the other  users’ password.

aci: (target="ldap:///dc=opensso,dc=java,dc=net")(targetattr="\*")(version 3.0; a
 cl "OpenSSO datastore configuration bind  user all rights under the root suffix"
 ; allow (all) userdn = "ldap:///cn=openssouser,ou=opensso adminusers,dc=opensso,
 dc=java,dc=net"; )

2.3.3 Add ACI to allow persistent search connection to the datastore configuration DN

OpenSSO relies on the persistent search notifications from the OpenDS for any change that occur in the directory server. For this purpose OpenSSO initiates a persistent connection as soon as the datastore is configured. By default OpenDS disallow persistent searches for the clients, to allow the persistent connection it needs to be enabled in the OpenDS, Adding the following ACI will make  this happen for the ‘openssouser’

aci:(targetcontrol = "2.16.840.1.113730.3.4.3")(version 3.0; acl "Allow Persiste
 nt Search for the OpenSSO datastore config bind user"; allow (all) userdn = "lda
 p:///cn=openssouser,ou=opensso adminusers,dc=opensso,dc=java,dc=net";)

2.3.4 Add ACI to prevent self modification of certain OpenSSO user attributes

Since OpenSSO extend the default OpenDS schema, we need to make sure the attributes that opensso uses are secure from being manipulated by using LDAP tools such as ldapmodify. For example OpenSSO relies on the attribute ‘inetusertstatus’ to determine whether an account is active or not. If this attribute is not protected from unauthorized modifications then one can easily change this value and become valid active user, to avoid this security breach following ACI must be added to the OpenDS user store.

aci: (targetattr = "objectclass || inetuserstatus || iplanet-am-user-login-statu
 s || iplanet-am-user-account-life || iplanet-am-session-quota-limit || iplanet-a
 m-user-alias-list ||  iplanet-am-session-max-session-time || iplanet-am-session-
 max-idle-time || iplanet-am-session-get-valid-sessions || iplanet-am-session-des
 troy-sessions || iplanet-am-session-add-session-listener-on-all-sessions || ipla
 net-am-user-admin-start-dn || iplanet-am-auth-post-login-process-class || iplane
 t-am-saml-user || iplanet-am-saml-password || iplanet-am-user-federation-info ||
 iplanet-am-user-federation-info-key || ds-pwp-account-disabled || sun-fm-saml2-
 nameid-info || sun-fm-saml2-nameid-infokey || sunAMAuthInvalidAttemptsData || me
 mberof || member")(targetfilter="(!(userdn=cn=openssouser,ou=opensso adminusers,
 dc=opensso,dc=java,dc=net))")(version 3.0; acl "OpenSSO User self modification d
 enied"; deny (write) userdn ="ldap:///self";)

3.0 Add the OpenSSO schema and supporting OpenDS configuration data

This is the critical part of this procedure, OpenSSO does leverage certain LDAPv3 compliant and attributes besides them there are few extra objectclasses/attributes are required to be added to the OpenDS to fully exploit the OpenSSO’s functionality.  You can download the complete schema file from here.

  • To load the schema , just do the following
  • ldapmodify -h localhost -p 5389 -D"cn=directory manager" -w dssecret12 -c  -f am_remote_opends_schema.ldif

  • To load the configuration data including the ACIs

ldapmodify -h localhost -p 5389 -D"cn=directory manager" -w dssecret12 -c  -a  -f configure_opends_userstore.ldif

This step completes the OpenDS preparation for the user store.
NOTE: You need to replace the following TAGs in the configure_opends_userstore.ldif

 TAG Name  Meaning  Value used in this document
 @ROOT_SUFFIX@  OpenDS suffix that is being configured as the base DN for the OpenSSO  dc=opensso,dc=java,dc=net
 @OPENSSO_USER_PASSWD@  This user will be used as the BIND DN in the datastore configuration this user should have read/write and passwd reset privilege amsecret12
@LDAP_USER_PASSWD@  This user will have read access to the users entries, this will be used in the policy configuration and LDAP authentication configuration  secret123

3.1 Enabling Referential Intergrity Plugin

You need to enable the referential integrity plugin in the OpenDS(some how out of the box it is not enabled) to make sure when the groups are removed from the directory all of its references in the users’ entries are removed automatically, if you dont enable this you would see the deleted groups will show up in the users’ profile even after the group has been removed from the directory server.

4.0 Create  User data store in OpenSSO

Once the steps 1 through 3 are accomplished successfully  you can go ahead and create a new LDAPv3 type datastore pointing to the OpenDS you have just configured.  I am going to show you the less error prone method to create the user store that point to OpenDS. I am assuming the ssoadm command line tool is already confgured with your OpenSSO server.

You just need to run  the following command

make sure you have replaced the  OpenDS server name and port  in the datastore_opends_attrs.txt. Now you can start creating and managing users that are stored in the OpenDS server. 

If you want to use this server as LDAP authentication source, you configure the LDAP auth instance with the bind user cn=ldapuser, like wise for the policy configuration service.

5.0 Removing the OpenSSO schema from OpenDS

At some point if you want to remove the schema added by the section 3.0, you can simply run the following command

ldapmodify -h localhost -p 5389 -D"cn=directory manager" -w dssecret12 -c  -f remove_am_remote_opends_schema.ldif

This will remove the OpenSSO  user schema.

6.0 Limitations

  • Currently OpenSSO dont support the extensive password policy provided by OpenDS
  • Only static groups are supported from OpenSSO console