Using OpenDS as user store for OpenSSO

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



  • /usr/bin/wget  http://www.opends.org/promoted-builds/1.2.0/OpenDS-1.2.0.zip

  • unzip -qo OpenDS-1.2.0.zip

  • cd OpenDS-1.2.0

  • ./setup --cli --no-prompt -Q -p 5389 --adminConnectorPort 5318 -D "cn=directory manager" -w "dssecret12" -a -b "dc=opensso,dc=java,dc=net"


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.


dn:dc=opensso,dc=java,dc=net
changetype:modify
add:aci
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.


dn:dc=opensso,dc=java,dc=net
changetype:modify
add:aci
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'


dn:dc=opensso,dc=java,dc=net
changetype:modify
add:aci
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.


dn:dc=opensso,dc=java,dc=net
changetype:modify
add:aci
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


Comments:

Hi Indira!

Very nice and useful article.

Can you tell me what functionalities are impacted if i don't give the opensso user any write permissions?

Kind Regards,
Florian

Posted by Florian Probst on March 10, 2009 at 01:09 AM PDT #

How can I use the console to managea remote OpenDS?

Posted by Carlos Crosetti on March 18, 2009 at 12:42 PM PDT #

Hi Indira,
Firt of all I wanted to thank you for this article and second thing is that I am a new to all this and would like to learn more stuff. I have this question and I wish you or some of your readers can help me with it. In our product we are actually using Sun One DS and Sun AM and we are planning to move to OpenDS and OpenSSO and I would like to know how can we perform schema and data migration from Sun DS to OpenDS.
Thanks.

Posted by Simo on March 19, 2009 at 06:07 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Indira Thangasamy, I manage the OpenSSO Quality engineering team.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today