Skip Headers

Oracle® Identity Management Integration Guide
10g Release 2 (10.1.2)
Part No. B14085-01
  Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index
Previous
Previous 		Next
Next 		 

15 Considerations for Integrating with Third-Party Directories

This chapter discusses the decisions you need to make before integrating with a third-party directory.


Note:

This chapter assumes that you are familiar with:

This chapter contains these topics:

Preliminary Considerations for Integrating with a Third-Party Directory

If you are deploying Oracle Internet Directory in an enterprise that already has an LDAP directory server, then you must configure both directories to co-exist in the same environment.

The co-existence of directories can require either of two different types of deployments:

Choose Which Directory Is to Be the Central Enterprise Directory

The central enterprise directory is the source of truth for all user, group, and realm information in the enterprise. It can be either Oracle Internet Directory or a third-party directory.

This section contains these topics:

Oracle Internet Directory as the Central Enterprise Directory

If Oracle Internet Directory is the central directory, then, once user, group, and realm objects are created, Oracle Internet Directory becomes the source of provisioning information for all Oracle components and third-party directories. The user and group objects for the entire enterprise are then provisioned in various Oracle components and third-party directories from Oracle Internet Directory.

Figure 15-1 shows a typical deployment in which Oracle Internet Directory is the central enterprise directory.

Figure 15-1 Interaction Between Components with Oracle Internet Directory as the Central Directory

This illustration is described in the text.
Description of the illustration oidag105.gif

As Figure 15-1 shows, when Oracle Internet Directory is the central enterprise directory, typical provisioning of a user or group follows this process:

  1. The user or group entry is created in Oracle Internet Directory by using the Oracle Internet Directory Self-Service Console, Oracle Directory Manager, or the command-line tools.

  2. At the next scheduled interval, that entry creation event is read by the third-party directory connector in Directory Integration and Provisioning.

  3. Following the mapping information in the integration profile, the user or group attributes in Oracle Internet Directory are appropriately mapped to the corresponding user or group attributes as required by the schema in the third-party directory.

  4. The user and group entry is created in the third-party directory.

A user entry is modified in Oracle Internet Directory, when:

  • A new attribute gets added to the entry

  • The value of an existing attribute is modified

  • An existing attribute is deleted

When Oracle Internet Directory is the central enterprise directory, the sequence of events during modification of a user or group entry is as follows:

  1. The entry is modified by using the Oracle Internet Directory Self-Service Console, Oracle Directory Manager, or the command-line tools.

  2. At the next scheduled interval, that entry modification event is read by the third-party directory connector in Directory Integration and Provisioning,

  3. Following the mapping information in the integration profile, the attribute in Oracle Internet Directory is appropriately mapped to the corresponding attribute in the connected directory

  4. The user entry is modified in the third-party directory.

Third-Party Directory as the Central Directory

If a third-party directory is the central directory, then, once user, group, and realm objects are created, the third-party directory becomes the source of provisioning information for all Oracle components and other directories. In this case, Oracle Internet Directory is deployed to support Oracle components. To provide this support, Oracle Internet Directory stores a footprint that enables it to identify entries in the third-party directory.

Figure 15-2 shows a typical deployment where a third-party directory is the central enterprise directory.

Figure 15-2 Interaction of Components with a Third-Party Directory as the Central Directory

This illustration is described in the text.
Description of the illustration oidag106.gif

Process for Provisioning of a User or Group

As Figure 15-2 shows, when a third-party directory is the central enterprise directory, typical provisioning of a user or group follows this process:

  1. The user or group entry is created in the third-party directory.

  2. At the next scheduled interval, the entry creation event is read by the third-party directory connector in Directory Integration and Provisioning.

  3. Following the mapping information in the integration profile, the user or group attributes in the third-party directory are mapped to the corresponding attributes in Oracle Internet Directory.

  4. The user or group entry is created in Oracle Internet Directory.

Process for Modifying a User or Group Entry

An entry is modified in the third-party directory when:

  • A new attribute gets added to the entry

  • The value of an existing attribute is modified

  • An existing attribute is deleted

When a third-party directory is the central enterprise directory, modification of a user or group entry follows this process:

  1. The entry is modified in the third-party directory.

  2. At the next scheduled interval, that entry modification event is read by the third-party directory connector in Directory Integration and Provisioning,

  3. Following the mapping information in the integration profile, the attribute in the third-party directory is appropriately mapped to the corresponding attribute in Oracle Internet Directory.

  4. The user or group entry is modified in Oracle Internet Directory.

As Figure 15-2 shows, when a third-party directory is the central enterprise directory, modification of passwords happens asynchronously in the directory that serves as the password repository. This happens by using plug-ins.

Choose Where to Store Passwords

Regardless of which directory is the central enterprise directory, the password can be stored in one or both directories. There are advantages and disadvantages to each option. This section compares the two options, and contains these topics:

Advantages and Disadvantages of Storing the Password in One Directory

By reducing to one the number of points of possible attack, storing the password in only one directory can make the password more secure. Moreover, it eliminates synchronization issues when the password is modified.

On the other hand, storing the password in one directory provides a single point of failure for the entire network. If the directory that fails is a third-party one, then even though user footprints are available in Oracle Internet Directory, users cannot access Oracle components.

Moreover, although storing passwords in only the central directory eliminates any possible synchronization issues, it requires you to enable applications to authenticate users to that directory. This involves using the appropriate plug-ins. For example, if you are using Microsoft Active Directory as both the central enterprise directory and the central password store, then you must enable applications to authenticate users to Microsoft Active Directory. You do this by using an external authentication plug-in. A similar mechanism is supported for authentication against SunONE Directory Server.


Note:

Oracle components use password verifiers to authenticate users, and, when passwords are stored in the third-party directory, those verifiers are not stored in Oracle Internet Directory. On the other hand, if a password is modified by using an Oracle component, then the verifiers are both generated and stored in Oracle Internet Directory.

Advantages and Disadvantages of Storing the Password in Both Directories

If you decide to store the password in both directories, then passwords need to be synchronized, ideally in real-time.

In Oracle Internet Directory 10g Release 2 (10.1.2), passwords are not synchronized in real time, but according to a schedule. This can mean an observable delay between the time the password is changed in the central directory and the time that the change is recorded in the other directory.

In deployments with Oracle Internet Directory as the central directory, password values are synchronized regularly from Oracle Internet Directory to the connected directory. This requires you to enable both the password policy of the realm and reversible encryption.


See Also:

In general, password values are hashed. If both directories use the same hashing algorithm, then the hashed values can be synchronized as they are. For example, suppose that you have an environment in which SunONE Directory Server and Oracle Internet Directory are integrated. Both of these directories support common hashing algorithms. Now, if the passwords are hashed and stored in SunONE Directory Server by using a hashing technique supported by Oracle Internet Directory, then synchronizing them from SunONE Directory Server to Oracle Internet Directory is the same as with any other attribute.

However if both directories do not support same hashing algorithm, then passwords must be synchronized in cleartext format only. For security reasons, password synchronization is possible with Oracle Internet Directory only in SSL Mode 2—that is, server-only authentication.

If Oracle Internet Directory is the source of truth, and if the hashing algorithm it supports is not supported by the other directory, then synchronization is still possible through SSL mode 2 (sslmode=2) when reversible password encryption is enabled.

If Microsoft Active Directory is the source of truth, then, when a password is modified in Microsoft Active Directory, a plug-in intercepts the password changes and stores the modified password in a new attribute, preferably in an encrypted form. That attribute can then be synchronized to Oracle Internet Directory. A similar process is required if Oracle Internet Directory is the central enterprise directory and central password store.


Note:

In deployments where both directories do not use the same hashing algorithm, password synchronization is not available in an out-of-the-box installation of Oracle Internet Directory. You must configure it.

In deployments where Oracle Internet Directory is not the central directory, the password policy is enforced by the third-party directory. When there is an authentication request to the third-party directory, the latter replies that the authentication either succeeded or failed. However, any detailed password policy errors from the third-party directory are not delivered to Oracle Internet Directory and then to the client applications.



See Also:

The following chapters for more detailed information about password synchronization:

The following chapter for information about plug-ins:


Choose the Structure of the Directory Information Tree

At installation, each directory server creates a default domain and a default directory information tree (DIT) structure. The Oracle Internet Directory infrastructure installation creates a default realm with designated containers for storing enterprise users and groups. When integrating with a third-party directory, you must create an identical DIT structures in both directories in order to use the default installation of Oracle Internet Directory. Alternatively, you can perform domain-level mapping.

This section contains these topics:

Create Identical DIT Structures on Both Directories

Oracle Corporation recommends that you configure identical DITs on both directories. This enables all the user and group objects to be synchronized as they are, and spares you the cumbersome task of mapping entries with distinguished names in one directory to URLs in the other. It also spares you the performance problems that such mapping can cause.

To create identical DITs, first decide which directory is the central enterprise directory, and then change the DIT of the other one to match. Be sure to update the directory integration and provisioning profile to reflect the domain level rules.

To enable users to access Oracle applications through Oracle Application Server Single Sign-On, Oracle Corporation recommends that you identify the DIT as a separate identity management realm with its own authentication and authorization domain.


See Also:

The chapter on deploying identity management realms in Oracle Internet Directory Administrator's Guide

Distinguished Name Mapping and Limitations

If it is not feasible to have identical DITs on both directories, then you need to map the domains between Oracle Internet Directory and the connected directory. For example, suppose that all entries under the container dc=mydir,dc=com must be synchronized under dc=myoid,dc=com in Oracle Internet Directory. To achieve this, you specify it in the domain level mapping rules.

If the objective is to synchronize all users and groups, then all user entries can be synchronized with appropriate DN mapping. However, group entry synchronization may be both time consuming and carry some additional limitations. This section provides examples of both user and group synchronization when there is a DN mapping.

Example: User Entry Mapping

Suppose that, in a mapping file, the entries in the SunONE Directory Server have the format uid=name,ou=people,o=iplanet.org. Suppose further that the entries in Oracle Internet Directory have the format cn=name,cn=users,dc=iplanet,dc=com. Note that the naming attribute on SunONE Directory Server is uid, but on Oracle Internet Directory it is cn.

The mapping file has rules like these: 

DomainRules
ou=people,o=iplanet.org: cn=users,dc=iplanet,dc=com: cn=%, cn=users,
dc=iplanet,dc=com
AttributeRules
Uid:1: :person:cn: :inetorgperson:

The value of 1 in the second column of the last line indicates that, for every change to be propagated from SunONE Directory Server to Oracle Internet Directory, the uid attribute must be present. This is because uid must always be available for constructing the DN of the entry in Oracle Internet Directory.

Example: Group Entry Mapping

When there is a DN mapping, synchronizing group entries is somewhat complex. The group memberships, which are DNs, must have valid DN values after synchronization. This means that whatever DN mapping was done for user DNs must be applied to group membership values.

For instance, suppose that the user DN values are mapped as follows: 

ou=people,o=iplanet.org: cn=users,dc=iplanet,dc=com:

This implies that all the user entries under ou=people,o=iplanet.org are moved to cn=users,dc=iplanet,dc=com.

Group memberships need to be mapped as follows: 

uniquemember: : : groupofuniquenames: uniquemember: :groupofuniquenames:
dnconvert(uniquemember)

For example, if the value of uniquemember is cn=testuser1,ou=people,o=iplanet.org, then it becomes cn=testuser1,cn=users,dc=iplanet,dc=com.

Moreover, if the value of uniquemember is cn=testuser1,dc=subdomain,ou=people,o=iplanet.org, then it becomes cn=testuser1,dc=subdomain,cn=users,dc=iplanet,dc=com.

This is a feasible solution as long as the naming attribute or RDN attribute remains the same on both the directories. However, if the naming attribute is different on different directories—as, for example, ou=people,o=iplanet.org:cn=users,dc=iplanet,dc=com:cn=%,cn=users,dc=iplanet,dc=com—then deriving the actual DNs for group memberships is not achievable through the given set of mapping rules. In this case, DN mapping for the uniquemember or other DN type attributes is not currently feasible.

If you want to synchronize group memberships, remember to keep the naming attribute in the source and destination directories the same.


See Also:

"Configuring Mapping Rules" for instructions on how to specify a mapping rule

Select the Attribute for the Login Name

The attribute for the login name contains the identity of the end user when logging into any Oracle component. It is stored in Oracle Internet Directory as the value of the attribute orclcommonnicknameattribute, under the container cn=common,cn=products,cn=oracleContext,identity_management_realm.

By default, orclcommonnicknameattribute has uid as its value. This means that the identity used for login is stored in the uid attribute of the user entry.

If the connected directory has a specific attribute for login, then that attribute needs to be mapped to the right orclcommonnicknameattribute in Oracle Internet Directory. This needs to be one of the mapping rules in the mapping file for the connector associated with synchronizing with the third-party directory.

For example, suppose that you are synchronizing Oracle Internet Directory with Microsoft Active Directory, and that, in the latter, the login identifier is contained in the userPrincipalName attribute of the user entry. You would synchronize the value of the userPrincipalName attribute to Oracle Internet Directory, storing it in the uid attribute, which is the value of the orclcommonnicknameattribute attribute. This mapping needs to be reflected in the mapping rules in the directory integration profile.

You can also use any other attribute for login. For example, if you want to use employeeID for logins, then mapping rules can be set accordingly. Doing this does not affect your configuration.


Note:

The orclcommonnicknameattribute attribute is used extensively by Oracle Application Server Single Sign-On, so be sure to plan carefully how you intend to map the attribute to a third-party directory attribute. After you modify this attribute, you must refresh Oracle Application Server Single Sign-On in order for the change to take effect.


See Also:

The Oracle Identity Management Guide to Delegated Administration for instructions on setting the attribute for login name

Select the User Search Base

The user search context is represented by a multivalued attribute that lists all the containers under which users exist. Depending on your deployment, either set the user search context value to cover the entire user population, or add the container to the user search context attribute by using the Oracle Internet Directory Self-Service Console.


See Also:

The Oracle Identity Management Guide to Delegated Administration for instructions on setting the user search context

Select the Group Search Base

The group search context is represented by a multivalued attribute that lists all the containers under which groups exist. Depending on your deployment, either set the group search context value to cover all group entries, or add the container to the group search context attribute by using the Oracle Internet Directory Self-Service Console.


See Also:

The Oracle Identity Management Guide to Delegated Administration for instructions on setting the group search context

Decide How to Address Security Concerns

There are three main security concerns you need to consider:

Step-by-Step Guide to Configuring Synchronization with a Third-Party Directory

This section lists the steps in configuring a sample deployment scenario.


Note:

"Step 4: Decide Whether to Create a New Identity Management Realm" through "Step 6: Select the Login Identifiers" involve configuring a new identity management realm and setting its parameters. This can affect the behavior of Oracle Application Server Single Sign-On and any other middle-tier application already installed in the environment. Consequently, make careful decisions at each step and verify the behavior of the applications.


See Also:

The chapter on deploying identity management realms in Oracle Internet Directory Administrator's Guide for more details on identity management realms and their role in Oracle Application Server.

This section contains these topics:

Step 1: Identify the Default Identity Management Realm in Oracle Internet Directory

Step 2: Identify the User and Group Search Bases in Oracle Internet Directory

Step 3: Identify the Naming Context on the Remote Directory

Step 4: Decide Whether to Create a New Identity Management Realm

Step 5: Select the User Search Base and Group Search Base

Step 6: Select the Login Identifiers

Step 7: Modify the Mapping File to Reflect the Changes You Have Made

Step 8: Create or Modify the Synchronization Profile with the New Set of Mapping Rules

Step 9: Configure Access Control

Step 10: Bootstrap the Directory by Using the Directory Integration and Provisioning Assistant

Step 11: Update the Last Change Number for Synchronization

Step 12: Enable the Profile by Using Either the Oracle Directory Integration and Provisioning Server Administration Tool or the Directory Integration and Provisioning Assistant

Step 13 (Optional): Enable the External Authentication Plug-in for Password Synchronization

Step 14: Start the Oracle Directory Integration and Provisioning Server

Step 1: Identify the Default Identity Management Realm in Oracle Internet Directory

To identify the default identity management realm in Oracle Internet Directory: 

ldapsearch –p port -h host -D distinguished_name -w password 
-b "cn=common, cn=products,cn=oraclecontext" -s base "objectclass=*"
orcldefaultsubscriber

In this sample deployment, the default identity management realm in Oracle Internet Directory is dc=us,dc=mycompany,dc=com.

Step 2: Identify the User and Group Search Bases in Oracle Internet Directory

To identify the user and group search contexts in Oracle Internet Directory: 

ldapsearch –p port -h host -D distinguished_name -w passwd 
-b "cn=common, cn=products,cn=oraclecontext, Identity Management Realm" 
-s base "objectclass=*"

Note down the values for the orclcommonusersearchbase and orclcommongroupsearchbase attributes. These are the values which are shown in the Oracle Internet Directory Self-Service Console as User Search Context and Group Search Context.

In this sample deployment, the user and group search contexts in Oracle Internet Directory are: 

orclcommonusersearchbase is : cn=users,  dc=us,dc=mycompany,dc=com
orclcommongroupsearchbase is : cn=groups,  dc=us,dc=mycompany,dc=com

Step 3: Identify the Naming Context on the Remote Directory

The default naming context is the root of the naming context under which the users are stored. Each directory has its own way of creating a default naming context.

If you are using Microsoft Active Directory, then you identify the default naming context by performing the following ldapsearch against that directory: 

ldapsearch –p port -h host -D distinguished_name -w password -b "" –s base "objectclass=*" defaultnamingcontext

Typically the DNs of users in Microsoft Active Directory are of the form cn=user name, cn=users, defaultnamingcontext.

Note that the users also can bind with names such as, username@domain.

For example, if the domain name is newcompany.com, then the default naming context is dc=newcompany,dc=com. The typical login identifier of a user is user@newcompany.com.

If you are using SunONE Directory Server, then you identify the naming contexts in that directory by performing the following ldapsearch against it: 

ldapsearch –p port -h host -D distinguished_name -w password -b "" –s base "objectclass=*" namingcontexts

Different sets of user entries reside in different subtrees. Choose the naming context that contains the objects to be synchronized.

Step 4: Decide Whether to Create a New Identity Management Realm

If the DITs on Oracle Internet Directory and the third-party directory are different, then it is better to create a new identify management realm and make it the default realm. Do this by using either the Oracle Internet Directory Self-Service Console or the Oracle Internet Directory Configuration Assistant. On the other hand, if the third-party directory is Microsoft Active Directory in which the default naming context is mycompany.com, then you may not have to create the new identity management realm.

Step 5: Select the User Search Base and Group Search Base

How you do this depends on whether you created a new identity management realm as discussed in the previous step.

If a new identity management realm has been created, then:

  1. Select the user search base and the user creation context. Do this by using the Oracle Internet Directory Self-Service Console. Set the user search context to reflect the container under which users are stored in the third-party directory. This is described in the Oracle Identity Management Guide to Delegated Administration.

    Follow the same approach to set the user creation context.

  2. Select the group search base and the group creation context. Do this by using the Oracle Internet Directory Self-Service Console. Set the group search context to reflect the container under which groups are stored in the third-party directory. This is described in the Oracle Identity Management Guide to Delegated Administration.

    Follow the same approach to set the group creation context.

If a new identity management realm has not been created, then, to enable user and group entries to be accessed by all Oracle components, you must modify the default parameters in the Oracle Internet Directory Self-Service Console. To do this:

  1. In the User Search Context, enter the DN of the users container in the third-party directory, or enter the subtree of the containers specified in the search context. For example, enter either of the following:

    cn=users,dc=myCompany,dc=com

    dc=myCompany,dc=com.

  2. In the Group Search Context, either enter the DN of the groups container in the third-party directory, or enter the subtree of the containers specified in the search context. For example, enter either of the following:

    cn=groups,dc=myCompany,dc=com

    dc=myCompany,dc=com


    See Also:

    The Oracle Identity Management Guide to Delegated Administration

Step 6: Select the Login Identifiers

The attribute used for login is orclcommonnicknameattribute. In the Oracle Internet Directory Self-Service Console, the field is named Attribute for Login Name. The default value is UID. Oracle Corporation recommends that you keep the default value. If this attribute is modified—for example, if it is changed to mail—then be sure that all entries under the container that you are working with have the mail attribute value populated. Otherwise, the user cannot login through Oracle Application Server Single Sign-On.

Step 7: Modify the Mapping File to Reflect the Changes You Have Made

The attributes you have just modified can require a change in the default mapping files. Look carefully at the various mapping rules and modify them according to the requirements. If the users and groups are under different containers, you may need to specify multiple set of domain rules in the same mapping file.

Default mapping rules for integration with SunONE Directory Server and Microsoft Active Directory are in the directory $ORACLE_HOME/ldap/odi/conf.

The important parameters to be modified are:

Step 8: Create or Modify the Synchronization Profile with the New Set of Mapping Rules

To do this, use the Directory Integration and Provisioning Assistant. 

dipassistant mp -profile profile_name odip.profile.mapfile=relative_path_name_of_mapping_file

Step 9: Configure Access Control

Configure access control to various containers in either of the following:

A sample ACI is available in $ORACLE_HOME/ldap/odi/samples/commonaci.ldif. This sample contains the following attributes, all of which have the same values:

You can use Oracle Directory Manager to set ACIs to these containers.

Step 10: Bootstrap the Directory by Using the Directory Integration and Provisioning Assistant

To bootstrap the directory, use the bootstrap command in the Directory Integration and Provisioning Assistant.


See Also:

Step 11: Update the Last Change Number for Synchronization

To do this, enter: 

dipassistant mp –profile profile_name -updlcn

The Directory Integration and Provisioning Assistant determines the connected directory by reading the directory integration profile.

Step 12: Enable the Profile by Using Either the Oracle Directory Integration and Provisioning Server Administration Tool or the Directory Integration and Provisioning Assistant

You can do this by using either the Oracle Directory Integration and Provisioning Server Administration tool or the Directory Integration and Provisioning Assistant.


See Also:

Step 13 (Optional): Enable the External Authentication Plug-in for Password Synchronization

If you need to synchronize password changes from Oracle Internet Directory to the third-party directory, then enable the external authentication plug-in by doing the following:

When passwords are synchronized to directories that do not support the hashing technique used by Oracle Internet Directory, synchronization can be done only by using the SSL mode 2 (sslmode=2).


See Also:

Step 14: Start the Oracle Directory Integration and Provisioning Server

Do this by following the instructions in "Starting the Oracle Directory Integration and Provisioning Server by Using the OID Control Utility".


Note:

To synchronize passwords, start Directory Integration and Provisioning with sslmode=2—that is, server-only authentication.

Limitations of Third-Party Integration in Oracle Internet Directory 10g Release 2 (10.1.2)

Oracle Internet Directory 10g Release 2 (10.1.2) does not support the synchronization of the schema and ACLs. If you are changing the schema or ACLs, then you must apply the changes manually. Use the schemasync tool to synchronize the schema between Oracle Internet Directory and a third-party directory.


See Also:

"The schemasync Tool Syntax" for information about the SchemaSync tool

  Previous
Previous 		Next
Next
  Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index