OpenAM: Oracle DSEE and Multiple Data Stores




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
        Read more about this book      

(For more resources on OpenSSO, see here.)

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-authid=cn=directory manager
<contents removed to save paper space >

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

        Read more about this book      

(For more resources on OpenSSO, see here.)

Datastore for OpenLDAP

OpenLDAP software is a free, open source implementation of the Lightweight Directory Access Protocol (LDAP) developed by the OpenLDAP project. It is released under its own BSD-style license called the OpenLDAP Public License. LDAP is a platform-independent protocol. Several common Linux distributions include OpenLDAP software for LDAP support. The software also runs on BSDvariants, as well as AIX, Android, HP-UX, Mac OS X, Solaris, Microsoft Windows (NT and derivatives, for example, 2000, XP, Vista, Windows 7, and so on), and z/OS. (

Many commercial websites and organizations rely on the OpenLDAP server for their everyday operations. Adoption of OpenLDAP is steadily growing with strong developer community support. Even though OpenSSO does not provide out of the box Identity Repository plugin implementation for the OpenLDAP, it is relatively easy to integrate an existing OpenLDAP infrastructure with the OpenSSO Single Sign-On framework for authentication and authorization. For read-only operations such as authentication and authorization there is no schema extension required in the OpenLDAP server side. In this case certain functionalities (refer to the User schema section in the article OpenAM Identity Stores: Types, Supported Types, Caching and Notification) of OpenSSO cannot be realized without extending the schema to include OpenSSO-specific object classes and attributes.

In this section I am going to show you a few simple steps to configure the OpenLDAP that can be used as a user identity store for OpenSSO. Here are the sequence of steps:

  • Configuring OpenLDAP suffix
  • Extending schema
  • Preparing the suffix with necessary entries
  • Creating the OpenLDAP data store
  • Testing the data store

Let us see how these steps can be accomplished in a less error-prone way.

Configuring an OpenLDAP suffix

There is a lot of information available on the Internet that describes how to install and configure the OpenLDAP server. In fact some of the Linux variants are automatically configured for OpenLDAP.

We are going to create a suffix dc=opensso,dc=java,dc=net with an administrative user, cn=manager who will be the root user for this suffix. The following command performs the recently mentioned items:

slapadd -d -1 < /tmp/init_suffix.ldif

where /tmp/init_suffix.ldif contained:

dn: dc=opensso,dc=java,dc=net
objectClass: top
objectClass: dcObject
objectClass: organization
o: opensso
dc: opensso
structuralObjectClass: organization

dn: cn=manager,dc=opensso,dc=java,dc=net
objectclass: inetuser
objectclass: organizationalperson
objectclass: person
objectclass: top
cn: manager
sn: manager
userPassword: secret12

This will create and initialize the suffix as shown in the LDIF we have just seen. Now you can issue:

ldapsearch -x -h -D"cn=manager,
dc=opensso,dc=java,dc=net" -w secret12 -b"dc=opensso,dc=java,
dc=net" "cn=*"

to verify the suffix configuration. Once this is successful you can go ahead and extend the schema by following the instructions in the next section.

Extending the schema

You should be able to download or find the schema file along with the code bundle. The schema file that contains the OpenSSO user schema for OpenLDAP is named as OpenSSO4OpenLDAP.schema. Copy this file to the OpenLDAP schema location, for example /etc/openldap/schema/. Then update the /etc/openldap/slapd.conf to include the schema after the default schema definitions. After updating the slapd.conf schema entries will look something like this:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/OpenSSO4OpenLDAP.schema

After this update restart the server to realize the schema extensions.

Preparing the suffix with necessary entries

There are certain entries that might help you to streamline the data store creation process and subsequent identity CRUD operations from the administrative console of OpenSSO. These are not a must but are recommended. Execute the following command to add the entries:

ldapmodify -x -h openldap -p 389 -D"cn=manager,dc=opensso,
dc=java,dc=net"-w secret12 -c -a -f /tmp/template.ldif

Here is how the contents of the file /tmp/template.ldif looks:

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: cn=amadmin,ou=people,dc=opensso,dc=java,dc=net
objectclass: inetuser
objectclass: organizationalperson
objectclass: person
objectclass: top
cn: amadmin
sn: amadmin
uid: amadmin
userPassword: secret124

objectclass: top
objectclass: groupofnames

This completes the LDAP server preparation process. Now let us see how OpenSSO can be configured to talk to this server for storing identities.

Creating an OpenLDAP data store

As I have mentioned earlier OpenSSO does not support an out of the box sub configuration in the Identity Repository service, we need to use the generic LDAPv3 sub configuration for OpenLDAP:

./ssoadm create-datastore -u amadmin -f /tmp/.passwd_of_amadmin
-e / -m
"OpenLDAP-store" -t LDAPv3 -D data_store_openldap.txt

This will create the data store in the OpenSSO configuration store. Note that there is no LDAPv3 configuration supported from the console, you need to always use the ssoadm tool to create the generic LDAPv3 configuration store. The file data_store_openldap.txt is available as part of the code bundle. You need to replace the openLDAP server name and port to match with your configuration.

Testing the data store

Once the data store is created successfully you can go ahead and log in to the OpenSSO console as the top level administrative user, then perform the user and group creation. User creation from the console will be seamless. However, the group creation will throw some exceptions, ignore them, they are harmless and there will be no functionality loss:

./ssoadm create-identity -i mytestgroup -t Group -u amadmin -f
/tmp/.passwd_of_amadmin -e /
Plug-in com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo: Unable
to findentry: cn=mytestgroup,ou=groups,dc=opensso,dc=java,

To verify the group has been created issue the following command:

./ssoadm list-identities -e / -t Group -u amadmin -f /tmp/
.passwd_of_amadmin -x "mytestgroup"
mytestgroup (id=mytestgroup,ou=group,dc=opensso,dc=java,dc=net)
Search of Identities of type Group in realm, / succeeded.

This completes the verification procedure along with the OpenLDAP schema extensions. There are some limitations that are known while using OpenLDAP as the user store. For instance there is no persistent search notification control (2.16.840.1.113730.3.4.3) implemented in OpenLDAP so you have to rely on the polling method to refresh the cache.

Multiple data stores

OpenSSO does support more than one data store to be configured for a given realm. In this scenario how can one fine-tune the specific privileges such as where to create users or groups. By default all the CRUD (create, read, update, and delete) operations will be applied to all of the available data stores unless the specific operations are disabled in the data store configuration page as shown in the following screenshot:

OpenAM: Oracle DSEE and Multiple Data Stores

If you want to control specific operations on the selected data stores, then you might want to remove the operations from the supported types and operations as previously shown. If you want to disable all the group-related operations then just remove the group=read,create,edit,delete from the data store configuration or remove create if you do not wish to create groups in that data store. In case there are some exceptions that have occurred in one of the data stores you will not notice this because those exceptions will be masked if one of the data stores successfully performs the requested operations.


In this article we took a look at some more supported identity stores and multiple identity stores. We also took a look at extending schema for OpenLDAP Identity Repository schema.

Further resources on this subject:

You've been reading an excerpt of:


Explore Title