OpenAM

Written and tested with OpenAM Snapshot 9—the Single Sign-On (SSO) tool for securing your web applications in a fast and easy way

• The first and the only book that focuses on implementing Single Sign-On using OpenAM
• Learn how to use OpenAM quickly and efficiently to protect your web applications with the help of this easy-to-grasp guide
• Written by Indira Thangasamy, core team member of the OpenSSO project from which OpenAM is derived
• Real-world examples for integrating OpenAM with various applications

Oracle Directory Server Enterprise Edition

The Oracle Directory Server Enterprise Edition type of identity store is predominantly used by customers and natively supported by the OpenSSO server. It is the only data store where all the user management features offered by OpenSSO is supported with no exceptions. In the console it is labeled as Sun DS with OpenSSO schema. After Oracle acquired Sun Microsystems Inc., the brand name for the Sun Directory Server Enterprise Edition has been changed to Oracle Directory Server Enterprise Edition (ODSEE). You need to have the ODSEE configured prior to creating the data store either from the console or CLI as shown in the following section.

Creating a data store for Oracle DSEE

Creating a data store from the OpenSSO console is the easiest way to achieve this task. However, if you want to automate this process in a repeatable fashion, then using the ssoadm tool is the right choice. However, the problem here is to obtain the list of the attributes and their corresponding values. It is not documented anywhere in the publicly available documentation for OpenSSO. Let me show you the easy way out of this by providing the required options and their values for the ssoadm:

./ssoadm create-datastore -m odsee_datastore -t LDAPv3ForAMDS -u
amadmin-f /tmp/.passwd_of_amadmin -D data_store_odsee.txt -e /

This command will create the data store that talks to an Oracle DSEE store. The key options in the preceding command are LDAPv3ForAMDS (instructing the server to create a datastore of type ODSEE) and the properties that have been included in the data_ store_odsee.txt. You can find the complete contents of this file as part of the code bundle provided by Packt Publishers. Some excerpts from the file are given as follows:

sun-idrepo-ldapv3-config-ldap-server=odsee.packt-services.
net:4355
sun-idrepo-ldapv3-config-authid=cn=directory manager
sun-idrepo-ldapv3-config-authpw=dssecret12
com.iplanet.am.ldap.connection.delay.between.retries=1000
sun-idrepo-ldapv3-config-auth-naming-attr=uid
<contents removed to save paper space >
sun-idrepo-ldapv3-config-users-search-attribute=uid
sun-idrepo-ldapv3-config-users-search-filter=(objectclass=
inetorgperson)
sunIdRepoAttributeMapping=
sunIdRepoClass=com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo
sunIdRepoSupportedOperations=filteredrole=read,create,edit,
delete
sunIdRepoSupportedOperations=group=read,create,edit,delete
sunIdRepoSupportedOperations=realm=read,create,edit,delete,
service
sunIdRepoSupportedOperations=role=read,create,edit,delete
sunIdRepoSupportedOperations=user=read,create,edit,delete,
service

Among these properties, the first three provide critical information for the whole thing to work. As it is evident from the name of the property they denote the ODSEE server name, port, bind DN, and the password. The password is in plain text so you need to remove the password from the input file after creating the data store, for security reasons.

Updating the data store

Like we discussed in the previous section, one can invoke the update-datastore sub command with the appropriate properties and its values along with the -a switch to the ssoadm tool. If you have more properties to be updated, then put them in a text file and use it with the -D option like the create-datastore sub command.

Deleting the data store

A data store can be deleted by just selecting it’s specific name from the console. There will be no warnings issued while deleting the data stores, and you could eventually delete all of the data stores in a realm. Be cautious about this behavior, you might end up deleting all of them unintentionally. Deleting data store does not remove any existing data in the underlying LDAP server, it only removes the configuration from the OpenSSO server:

./ssoadm delete-datastores -e / -m odsee_datastore -f /tmp/
.passwd_of_amadmin -u amadmin

Data store for OpenDS

OpenDS is one of the popular LDAP servers that is completely written in Java and available freely under open source license. As a matter of fact the embedded configuration store that is built in the OpenSSO server is the embedded version of OpenDS. It has been fully tested with the OpenDS standalone version for the identity store usage. The data store creation and management are pretty much similar to the steps described in the foregoing section, except the type of store and the corresponding properties’ values. The properties and their values are given in the file data_store_opends.txt (available as part of code bundle). Invoke the ssoadm tool with this property file after making appropriate changes to fit to your deployment. Here is the sample command that creates the datastore for OpenDS:

./ssoadm create-datastore -u amadmin -f /tmp/.passwd_of_amadmin
-e / -m
“OpenDS-store” -t LDAPv3ForOpenDS -D data_store_opends.txt

Data store for Tivoli DS

The IBM Tivoli Directory Server 6.2 is one of the supported LDAP servers for the OpenSSO server to provide authentication and authorization services. A specific sub configuration LDAPv3ForTivoli is available out of the box to support this server. You can find the data_store_tivoli.txt to create a new data store by supplying the -t LDAPv3ForTivoli option to the ssoadm tool. Here is the sample command that creates the datastore for Tivoli DS. The sample (data_store_tivoli. txt can be found as part of the code bundle) file contains the entries including the default group, that are shipped with the Tivoli DS for easy understanding. You can customize it to any valid values:

./ssoadm create-datastore -u amadmin -f /tmp/.passwd_of_amadmin
-e / -m
“Tivoli-store” -t LDAPv3ForTivoli -D data_store_tivoli.txt

Data store for Active Directory

Microsoft Active Directory provides most of the LDAPv3 features including support for persistent search notifications. Creating a data store for this is also a straightforward process and is available out-of-the-box. You can find the data_ store_ad.txt to create a new data store by supplying the -t LDAPv3ForAD option to the ssoadm tool. Here is the sample command that creates the datastore for AD:

./ssoadm create-datastore -u amadmin -f /tmp/.passwd_of_amadmin
-e / -m
“AD-store” -t LDAPv3ForAD -D data_store_ad.txt .

Data store for Active Directory Application Mode

Microsoft Active Directory Application Mode (ADAM) is the lightweight version of the Active directory with simplified schema. In the ADAM instance it is possible to set user password over LDAP unlike Active Directory where password-related operations must happen over LDAPS. Creating a data store for this is also a straightforward process and is available out-of-the-box. You can find the data_store_adam. txt to create a new data store by supplying the -t LDAPv3ForADAM option to the ssoadm tool:

./ssoadm create-datastore -u amadmin -f /tmp/.passwd_of_amadmin
-e / -m
“ADAM-store” -t LDAPv3ForADAM -D data_store_adam.txt