Chapter 15 Enabling the Access Manager SDK (AMSDK) Identity Repository Plug-in

Enabling the Access Manager SDK (AMSDK) Identity Repository (IdRepo) legacy plug-in allows Sun OpenSSO Enterprise to use the following features:

• Role-based authentication

• Role-based services

Contents

• Requirements to Enable the AMSDK Identity Repository Plug-in

• Configuring Sun Java System Directory Server

• Configuring OpenSSO Enterprise Server

• Creating a Data Store Using the AMSDK Plug-in

Requirements to Enable the AMSDK Identity Repository Plug-in

The requirements to enable and use the AMSDK Identity Repository plug-in include:

• The opensso.war file must be deployed in a supported web container, and OpenSSO Enterprise server must be initially configured using either the GUI or command-line Configurator.

• Sun Java System Directory Server must be the OpenSSO Enterprise user data store.

Configuring Sun Java System Directory Server

Configuring Directory Server involves loading the required object classes, attributes, and objects, which are available in the following LDIF files:

• zip-root/opensso/ldif/sunone_schema2.ldif

• zip-root/opensso/ldif/ds_remote_schema.ldif

• config_dir/template/ldif/install.ldif

• zip-root/opensso/ldif/index.ldif

• zip-root/opensso/ldif/plugin.ldif

• zip-root/opensso/ldif/fam_sds_schema.ldif

where:

• zip-root is where the opensso_enterprise_80.zip file was unzipped.

• config_dir is the configuration directory specified during the initial configuration of opensso.war. For example: /opensso

Before you modify these LDIF files, be sure to back up each file.

Configure Directory Server by loading the required object classes and attributes by following one of these processes:

• To Configure an Existing Directory Server With Access Manager 7.x User Data Store

• To Configure a New Directory Server

To Configure an Existing Directory Server With Access Manager 7.x User Data Store

This task describes how to configure an existing Directory Server identity repository that was previously deployed with Access Manager 7.1 or Access Manager 7 2005Q4, in either legacy or realm mode.

1. Load the following object classes to the Directory Server schema from the fam_sds_schema.ldif file:

   • sunFederationManagerDataStore

   • sunFMSAML2NameIdentifier

   Note: The fam_sds_schema.ldif file also includes the sunIdentityServerLibertyPPService object class. If you don't want to load this object class, comment out the appropriate line before you load the file.

   To load these object classes, use the Directory Server Console, Directory Service Command Center (DSCC), or a command-line utility such as ldapmodify.

2. Continue with Configuring OpenSSO Enterprise Server .

To Configure a New Directory Server

1. In the following LDIF files, replace the tags marked by ampersands (@):

   • config_dir/template/ldif/install.ldif

     • @NORMALIZED_RS@ with the normalized root suffix. For example: o=example,o=isp

     • @RS_RDN@ with the relative DN of the root suffix. For example: example

     • @ORG_NAMING_ATTR@ with the organization naming attribute. For example: o

     • @ADMIN_PWD@ with the passwords for dsameuser and puser (an occurrence for each user)

     • @AMLDAPUSERPASSWD@ with the password for amldapuser

     • @SERVER_HOST@ with the fully qualified host name. For example: host.example.com

     • @ORG_OBJECT_CLASS@ with the organization object class. For example: sunmanagedisorganization

     • @People_NM_ORG_ROOT_SUFFIX@ with the administrator for the people container (that is, the role that will manage the people container). For example: opensso_dc=java_dc=net

   • zip-root/opensso/ldif/index.ldif

     • @ORG_NAMING_ATTR@ with the organization naming attribute. For example: o

     • @DB_NAME@ with the backend DB name. For example: openssso

2. Load the following LDIF files, in the order shown:

   • zip-root/opensso/ldif/sunone_schema2.ldif

   • zip-root/opensso/ldif/ds_remote_schema.ldif

   • config_dir/template/ldif/install.ldif

   • zip-root/opensso/ldif/index.ldif

   • zip-root/opensso/ldif/plugin.ldif

   • zip-root/opensso/ldif/fam_sds_schema.ldif

   To load these LDIF files, use the Directory Server Console, Directory Service Command Center (DSCC), or a command-line utility such as ldapmodify.

Configuring OpenSSO Enterprise Server

You must configure OpenSSO Enterprise server for the AMSDK Identity Repository plug-in, using the ssoadm command. Consider these two scenarios to determine the steps you follow:

• Scenario 1: You do not want to customize the DAI service (ums.xml file). Follow Configuring OpenSSO Enterprise Server Using the ssoadm Command with add-amsdk-idrepo-plugin Subcommand.

• Scenario 2: You want to customize the DAI service (ums.xml file). Follow Configuring OpenSSO Enterprise Server Manually.

After you follow either scenario, continue with Creating a Data Store Using the AMSDK Plug-in.

Configuring OpenSSO Enterprise Server Using the ssoadm Command with add-amsdk-idrepo-plugin Subcommand

In this scenario, you do not want to customize the DAI service (ums.xml file). The ssoadm command with the add-amsdk-idrepo-plugin subcommand configures OpenSSO Enterprise server to enable the AMSDK Identity Repository plug-in by performing all of these tasks:

• Loads the Directory Access Instructions (DAI) service

• Adds the IdRepo subschema (sunIdentityRepositoryService)

• Updates the Directory Server information in serverconfig.xml

• Enables persistent searches for the AMSDK Identity Repository plug-in

To Configure OpenSSO Enterprise Server Using the ssoadm Command and add-amsdk-idrepo-plugin Subcommand

1. Execute the ssoadm command with the add-amsdk-idrepo-plugin subcommand. For example:

   # ./ssoadm add-amsdk-idrepo-plugin -u amadmin -f ./password-file \
   -a user-naming-attribute -o oranization-naming-attribute \
   -b "dc=example,dc=com" -s ldaphost.example.com:389 \
   -x ./dsamepassword -p ./proxypassword

   where:

   -u specifies the administrative user. For example: amadmin

   -f specifies the password file for the administrative user.

   -a and -o specify the user naming attribute and organization naming attribute, respectively. Both parameters are optional. The default values are uid and o.

   -b specifies the base DN of the Directory Server in which the Access Manager repository is being configured. For example: dc=example,dc=com

   -s specifies the directory server host, port, and protocol. Examples for the -s option are:

   • ldap://host:port

   • host:port (The protocol defaults to ldap.)

   • host (The protocol defaults to ldap, and the port defaults to 389.)

   -x specifies the password file for dsameuser.

   -p specifies the password file for proxyuser.

   On Solaris and Linux systems, the password files specified by -x and -p must have 400 (read-only by owner) permissions.

2. Restart the OpenSSO Enterprise server web container.

3. Continue with Creating a Data Store Using the AMSDK Plug-in.

Configuring OpenSSO Enterprise Server Manually

In this scenario, you want to customize the DAI service (ums.xml file), so you must configure OpenSSO Enterprise server manually by:

• Loading the Directory Access Instructions (DAI) Service

• Loading the AMSDK Subschema

• Updating the Directory Server Information for the AMSDK Plug-in

• Enabling Persistent Search Connections for the AMSDK Plug-in

Loading the Directory Access Instructions (DAI) Service

To Load the DAI Service

1. In the zip-root/opensso/xml/ums.xml file, replace the following items, as needed for your deployment:

   • @USER_NAMING_ATTR@ with your user naming attribute. For example, uid (which is the default)

   • @ORG_NAMING_ATTR@ with your organization naming attribute. For example, o (which is the default)

2. Load the DAI service from the ums.xml file using the ssoadm command with the create-svc subcommand. For example:

   # ./ssoadm create-svc -u amadmin -f ./password-file \
   --xmlfile zip-root/opensso/xml/ums.xml

   where:

   -u specifies the administrative user. For example: amadmin

   -f specifies the password file for the administrative user.

   --xmlfile (or -X) specifies the path to the ums.xml file.

   zip-root is where the opensso_enterprise_80.zip file was unzipped.

Loading the AMSDK Subschema

To Load the AMSDK Subschema

1. In zip-root/opensso/xml/idRepoAmSDK.xml, replace @NORMALIZED_ORGBASE@ with the Directory Server root suffix.

2. Load the IdRepo subschema using the ssoadm command with the add-sub-schema subcommand. For example:

   # ./ssoadm add-sub-schema -u amadmin -f ./password-file \
   -s sunIdentityRepositoryService -t Organization -F zip-root/opensso/xml/idRepoAmSDK.xml

   where:

   -u specifies the administrative user. For example: amadmin

   -f specifies the password file for the administrative user.

   -s specifies the service name. Must be sunIdentityRepositoryService

   -t specifies the schema type. Must be: Organization

   -F specifies the path to the idRepoAmSDK.xml file.

Updating the Directory Server Information for the AMSDK Plug-in

Update the Directory Server information by exporting, modifying, and then re-importing the information.

Important: If your deployment has multiple OpenSSO Enterprise server instances, you must perform the following steps on all server instances.

To Update the Directory Server Information for the AMSDK Plug-in

1. Export the Directory Server configuration information from the OpenSSO Enterprise server instance using the ssoadm command with the get-svccfg-xml subcommand. For example:

   # ./ssoadm get-svrcfg-xml -u amadmin -f ./password-file \
   -s http(s)://host.domain:port/opensso -o serverconfig.xml

   where:

   -u specifies the administrative user. For example: amadmin

   -f specifies the password file for the administrative user.

   -s specifies the server instance name. For example: https://openssohost1.example.com:8080/opensso

   -o specifies the output file name that will contain the Directory Server configuration information. For example: serverconfig.xml

2. Edit the Directory Server configuration information in the serverconfig.xml file as follows:

   1. In the <ServerGroup name="default" ...> entry, add the Directory Server configuration information, including the host, port and protocol.

   2. Update the encrypted passwords for the admin and proxy users. Use the ampassword utility to obtain the encrypted passwords

3. Import the revised Directory Server configuration information using the ssoadm command with the set-svccfg-xml subcommand. For example:

   # ./ssoadm set-svrcfg-xml -u amadmin -f ./password-file \
   -s http(s)://host.domain:port/opensso -X serverconfig.xml

   where:

   -u specifies the administrative user. For example: amadmin

   -f specifies the password file for the administrative user.

   -s specifies the server instance name. For example: http://openssohost1.example.com:8080/opensso

   -X specifies the input file name that contains the revised Directory Server configuration information. For example: serverconfig.xml

Enabling Persistent Search Connections for the AMSDK Plug-in

This task involves enabling the persistent search (psearch) connections for the OpenSSO Enterprise server to allow the AMSDK Identity Repository plug-in to receive change notifications.

To Enable Persistent Search Connections for the AMSDK plug-in

1. Log in to the OpenSSO Enterprise Admin Console.

2. Click Configuration and then Servers and Sites.

3. For each OpenSSO server instance listed:

   1. Click SDK and then Event Service.

   2. Remove the entries in Disabled Event Service Connection.

   3. Click Save.

4. Log out of the Console.

5. Restart the OpenSSO Enterprise server web container.

Creating a Data Store Using the AMSDK Plug-in

Use the following procedure to create a new data store or to verify that you correctly enabled the AMSDK Identity Repository plug-in.

To Create a Data Store Using the AMSDK Plug-in

1. Log in to the OpenSSO Enterprise Administration Console as amadmin.

2. Click Access Control.

3. Under Realm Name, click the name of the realm.

4. Click Data Stores.

5. Click New.

6. For Select Type of Data Store, check Access Manager Identity Repository Plug-in.

7. Enter the Data Store Name, and click Next to continue the configuration.

   (Or, if you are not actually creating a new data store, click Cancel.)

8. If you are creating a new data store, provide the required configuration values.

   For other fields, either accept the default values or provide values appropriate for your deployment.

9. Click Finish to complete the configuration.