Sun Java System Federation Manager 7.0 User's Guide

Modifying Federation Manager Configuration Data to Recognize an LDAPv3–compliant Directory

After installing your LDAPv3–compliant directory you must reconfigure certain of the Federation Manager configuration data before migrating it to the directory. If the Federation Manager WAR is exploded, you must restart the web container after making these changes. If the Federation Manager WAR is not exploded, make your changes in the staging directory (located by default in the IS_INSTALL_VARDIR/war_staging directory where IS_INSTALL_VARDIR is defined in the silent installation file detailed in The Silent Installation File), regenerate the WAR, and deploy the modified WAR. The following instructions assume that the WAR has been exploded.

ProcedureTo Set Up Federation Manager for an LDAPv3–compliant Directory

Before You Begin

If Federation Manager is working solely against an LDAPv3–compliant directory, you must create two users in the directory with the correct read and write privileges to the ou=services tree: amadmin and dsameuser. See serverconfig.xml Users.

  1. Install Federation Manager according to the instructions in Chapter 2, Installing and Deploying Federation Manager.

  2. Edit the default ServerGroup in the serverconfig.xml file as follows:

    • Change the host, port, and type attributes of the Server tag to reflect your directory's installation.

    • Change the DirDN and DirPassword attributes of the User tag in both the proxy and admin entries to reflect an existing user DN and password (encrypted using ampassword). Alternately, you can  create a new administrator in the directory. This new user must have read, search, write and delete permission on the ou=services subtree of the directory information tree (DIT) containing the Federation Manager configuration data once the data store has been changed to Open LDAP.


      Note –

      Ensure the proper user permissions have been allocated. This should be done after running fmff2ds.


    • Change the values of the BaseDN to that of the parent DN containing the configuration data. For example, dc=sun,dc=com.

    See

  3. Edit the AMConfig.properties file as follows:

    • Change the value of the com.sun.identity.sm.sms_object_class_name property to com.sun.identity.sm.ldap.SMSLdapObject.

    • If the DirDN specified in the step above is different from the default amadmin, you need to modify the com.sun.identity.authentication.special.users property by adding (or replacing) the specified DN of the directory's super user. This property may contain a pipe-separated list of user DNs as in: com.sun.identity.authentication.special.users=cn=dsameuser,ou=DSAME Users,dc=sun,dc=com|cn=administrator,cn=users,dc=sun,dc=com.

    AMConfig.properties is located in the /exploded-FM-WAR-directory/WEB-INF/classes directory where exploded-FM-WAR-directory is the directory to which the Federation Manager WAR was deployed.

  4. Run fmff2ds according to the information in Building and Loading LDIF Configuration Data Using fmff2ds.

  5. Restart the web container.

    Federation Manager is now communicating with Directory Server.

ProcedureTo Add a Second Instance of Federation Manager to the Server List

This procedure is useful when an LDAPv3–compliant directory is used for storing configuration data. If creating a second instance of Federation Manager by running fmwar, you will need to add the new instance to the Server List attribute of the original instance of Federation Manager before starting the new instance. The following procedure describes how to do this.

  1. Login to the console of the original instance of Federation Manager as administrator.

  2. Select the Configuration tab.

  3. Select Platform under System Properties.

  4. Enter the new instance in the Server List global attribute and click Add.

    The value is entered in the form protocol://host-name:port|instance-name. For example, http://host2.sun.com:81|02.