Identity stores in OpenSSO serves as the key feature for authentication and authorization. These are predominantly Lightweight Directory Access Protocol, or LDAP servers. There are multiple types of LDAP servers tested and certified with OpenSSO as identity stores. Almost all of the market-leading commercial LDAP servers are supported. In this section let us explore how to create and manage identity stores for each type of LDAP server. Each LDAP server has its own sub configuration identifier in the Identity Repository schema definition. The database plugin is only an early access feature; hence, we will not be covering here.
When a new identity user store is created from the console or CLI, the OpenSSO server creates a configuration entry in its configuration store followed by loading the OpenSSO-specific schema into the corresponding LDAP servers provided. The LDAP user provided (sun-idrepo-ldapv3-config-authid) should have read and write access to the base (sun-idrepo-ldapv3-config-organization_name) distinguished name (DN) and the schema configuration DN.
To take advantage of the authentication lockout, password reset, and federation features of OpenSSO, one needs to extend the underlying LDAP servers' schema to accommodate OpenSSO-specific object classes and attributes. This schema extension is done automatically for the supported LDAP servers discussed in this section with exception of OpenLDAP. Even though it is possible to work with these directories without extending the schema, you cannot manage the data store configuration from the OpenSSO administrative console, and the following functionalities will not be available:
- User account lockout in multi-server configuration
- User account expiry
- Password reset
- Extensive federation features such as IDFF PP service
- User-based authentication, session constraint, success, and failure URLs
The specific schema files and associated entries for each directory server will be kept under the<conf-dir>/ldif directory. These files are created at the time of the OpenSSO server configuration. These LDIF files will be consumed by the Identity Repository framework either at the time of server configuration or at the point when the checkbox Load schema when saved: is enabled while saving the data store configuration from the administrative console. This option is not available from the ssoadm CLI tool. So just creating the data store does not load the schema into the backend directory server, it adds the schema only when the previously mentioned checkbox is checked. You can safely test a read-only data store when needed. The checkbox is enabled, and you can safely test a read-only data store when needed by disabling this checkbox.
Now let us see how each type of data store can be created. As usual this process can be achieved via the administrative console (Access Control | Top Level Realm | Data Stores) or ssoadm CLI tool. As it is trivial from the console, I will show you how to manage the data stores using the CLI tool.
This type of Identity Repository is not available in the out of the box configuration; the administrator has to explicitly configure the server to enable the plugin. The default configuration will support the repository types as shown in the following screenshot:
The Access Manager Repository plugin is also called amSDK or legacy SDK as it provides downward compatibility to work with the existing Sun Access Manager 7.x version deployment identity stores. This repository is tightly coupled with the Oracle DSEE server; hence, will not work with any other LDAP servers. To enable this plugin invoke the following command (there is no console user interfaces for this):
./ssoadm add-amsdk-idrepo-plugin -u amadmin -f /tmp/.passwd_of_amadmin -b dc=opensso,dc=java,dc=net -s ldap://dsee.packt-services.net:4355 -x /tmp/.passwd_of_amadmin -p /tmp/.passwd_of_amadmin -v -a uid -o o -e 'cn=Directory Manager' -m /tmp/.passwd_of_dir_mgr
Once this command is successful, you will be able to create amSDK plugin after restarting the server. The list of supported data stores will include the Access Manager Repository plugin as follows:
Access Manager Repository plugin or amSDK data store can be created from a console interface or from CLI (the former is a trivial process). Let us use ssoadm to accomplish this. Here is how you can create the datastore:
ssoadm create-datastore -e / -u amadmin -f /tmp/.passwd_of_amadmin -t amSDK -D /tmp/mydata -m datastoreforamsdk
where /tmp/mydata contains the following attributes:
sun-idrepo-amSDK-config-copyconfig-enabled=false amSDKOrgName=dc=opensso,dc=java,dc=net sun-idrepo-amSDK-config-people-container-name=ou sun-idrepo-amSDK-config-recursive-enabled=false sun-idrepo-amSDK-config-people-container-value=people sunIdRepoClass=com.iplanet.am.sdk.AMSDKRepo
These attributes can be edited from the console as shown in the following screenshot. As you can see there are no options to change the directory server settings. To change the directory server-related information you need to navigate to Configuration | Server and Sites | Instance | Directory Configuration. From this location you will be able to update the directory server settings.
Now you can start creating user and/or role objects in the new repository. One exception here is that the Load schema when finished does not have any impact, as the schema will be loaded when you invoke the add-amsdk-idrepo-plugin subcommand.
In case you want to view the properties of the data store that you have created, you can leverage the show-datastore sub command as shown in the following:
./ssoadm show-datastore -e / -m datastoreforamsdk -u amadmin -f /tmp/.passwd_of_amadmin
sunIdRepoNamingAttribute=role=cn
sunIdRepoNamingAttribute=user=uid
sunIdRepoNamingAttribute=group=cn
sunIdRepoNamingAttribute=filteredrole=cn
sun-idrepo-amSDK-config-copyconfig-enabled=false
amSDKOrgName=dc=opensso,dc=java,dc=net
sunIdRepoAttributeMapping=
RequiredValueValidator=com.sun.identity.sm.RequiredValueValidator
sun-idrepo-amSDK-config-people-container-value=people
sun-idrepo-amSDK-config-people-container-name=ou
sunIdRepoSupportedOperations=group=read
sunIdRepoSupportedOperations=role=read,edit,service
sunIdRepoSupportedOperations=user=read,create,edit,delete,service
sunIdRepoSupportedOperations=filteredrole=read,edit,service
sunIdRepoClass=com.iplanet.am.sdk.AMSDKRepo.
sun-idrepo-amSDK-config-recursive-enabled=false
This will be handy if you want to view the value of a specific property or to update a specific property for which you don't know the property name. This command will dump all the data store properties.
Like any other object, one can update the specific properties of an existing data store using the command line tool, ssoadm. For example: the following command after successful execution will change the property sun-idrepo-amSDK-config-recursive-enabled value from false to true:
./ssoadm update-datastore -e / -m datastoreforamsdk -f /tmp/.passwd_of_amadmin -u amadmin -a "sun-idrepo-amSDK-config-recursive-enabled=true"
In this manner you can change any property whose value needs to be updated.
Finally let us close the loop by showing you how an existing data store can be deleted using the delete-datastores subcommand.
./ssoadm delete-datastores -e / -m datastoreforamsdk -f /tmp/.passwd_of_amadmin -u amadmin
This will only remove the data store named datastoreforamsdk but will not remove the schema or Access Manager Repository plugin from the server. The sequence of commands given in the following section will remove the schema from the server.
In case you want to remove the Access Manager Repository plugin from the server, you need to remove the subschema entry that is part of the Identity Repository service and the DAI service. Here is the procedure to remove them in order. There is no other interface to perform these actions:
./ssoadm remove-sub-schema -s sunIdentityRepositoryService -t Organization -a amSDK -u amadmin -f /tmp/.passwd_of_amadmin
./ssoadm delete-svc -s DAI -u amadmin -f /tmp/.passwd_of_amadmin
The one exception here is that the delegation policies will not be removed.
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 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.
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.
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
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
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
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 .
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 straight-forward 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
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 BSD-variants, 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. (http://en.wikipedia.org/wiki/OpenLDAP).
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) 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.
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 openldap.packt-services.net -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.
You should be able to download or find the schema file along with the code bundle you got with this book. 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.
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 ou:people objectClass: organizationalUnit dn: ou=groups,dc=opensso,dc=java,dc=net ou:groups 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 dn:cn=defaultGroup,ou=groups,dc=opensso,dc=java,dc=net objectclass: top objectclass: groupofnames member:cn=amadmin,ou=people,dc=opensso,dc=java,dc=net cn:default1
This completes the LDAP server preparation process. Now let us see how OpenSSO can be configured to talk to this server for storing identities.
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.
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 find entry: cn=mytestgroup,ou=groups,dc=opensso,dc=java,dc=net
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.
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:
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.