Directory Information Tree in an Integration with a Third-Party Directory

This section contains these topics:

■ About Realms in Oracle Internet Directory

■ Planning the Deployment

■ Example: Integration with a Single Third-Party Directory Domain

See Also: Oracle Fusion Middleware Guide to Delegated Administration for Oracle Identity Management

See Also: Oracle Fusion Middleware Administrator's Guide for Oracle Single Sign-On for information about OracleAS Single Sign-On Server

Concepts and Architecture of Third-Party Directory Integration

16.1.3.1 About Realms in Oracle Internet Directory

In Oracle Internet Directory, an identity management realm defines an enterprise scope over which certain identity management policies are defined and enforced by the deployment. It comprises:

■ A well-scoped collection of enterprise identities—for example, all employees in the US domain.

■ A collection of identity management policies associated with these identities. An example of an identity management policy would be to require that all user passwords have at least one alphanumeric character.

■ A collection of groups, that is, aggregations of identities that simplify setting the identity management policies

Multiple Realms

You can define multiple identity management realms within the same Oracle Identity Management infrastructure. This enables you to isolate user populations and enforce a different identity management policy,—for example, password policy, naming policy, self-modification policy—in each realm. This is useful in a hosted deployment of Oracle Fusion Middleware.

Each identity management realm is uniquely named to distinguish it from other realms. It also has a realm-specific administrator with complete administrative control over the realm.

The Default Realm

For all Oracle components to function, an identity management realm is required. One particular realm, created during installation of Oracle Internet Directory, is called the default identity management realm. It is where Oracle components expect to find users, groups, and associated policies whenever the name of a realm is not specified.

This default realm facilitates proper organization of information and enforces proper access controls in the directory.

There can be only one default identity management realm in the directory. If a

deployment requires multiple identity management realms, then one of them must be chosen as the default.

Figure 16–1 illustrates the default identity management realm.

See Also: The chapter on directory concepts and architecture in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for a fuller discussion of directory information trees

Concepts and Architecture of Third-Party Directory Integration

Figure 16–1 The Default Identity Management Realm

As Figure 16–1 shows, the default identity management realm is part of a global DIT.

The node that follows the root DSE is dc=com, followed by dc=MyCompany, then dc=us. These four nodes represent the overall DIT structure. The node dc=us is the root of the default identity management realm. It has two subtrees for containing user and group information: cn=Users and cn=Groups. For illustration purposes, the cn=Users node contains two leaves: uid=user1 and uid=user2. Similarly, the cn=Groups node contains cn=group1 and cn=group2.

Access Control Policies in the Realm

You must configure appropriate ACLs in Oracle Internet Directory to enable Oracle Directory Integration Platform to:

■ Enable the import profile to add, modify and delete objects in the users and groups containers. By default, import profiles are part of the Realm

Administrators group, which can perform all operations on any entry under the realm DN. If you have customized ACLs in the realm, then be sure that the import profiles have the appropriate privileges to perform these operations on the subtree to be synchronized or on either the user container, the group container, or both depending on where the synchronization takes place.

■ Enable Oracle components to manage the users and groups in the realm. By default, Oracle components can manage users and groups in the users and groups containers respectively. If you have updated your usersearchbase and groupsearchbase in the realm, then set up appropriate ACLs on the users container and groups container.

16.1.3.2 Planning the Deployment

When planning the DIT, the most important decisions to make before synchronization are:

■ Which directory is to be the central one

See Also: The chapter on deployment of Oracle Identity

Management realms in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for a description of the default realm installed with Oracle Internet Directory

cn=Groups

User / Group Naming and Containment Overall

DIT Structure

Concepts and Architecture of Third-Party Directory Integration

■ What objects to synchronize, for example:

– The portion of the DIT that you want to synchronize. You can synchronize the entire DIT or just a portion of it.

– For each entry, the specific contents that you want to synchronize. You can synchronize the entire content of the entry or just a portion of it.

■ Where to synchronize. You have two options:

– You can synchronize so that the relative position of each entry in the DIT is the same in the source and destination directories. This configuration, called one-to-one distinguished name mapping, is the most commonly used configuration. Because the source DN is the same as the destination DN, this configuration provides better performance than when the two DNs are different.

– You can synchronize so that the relative position in the DIT of each entry in the destination directory is different from that in the source directory. In this configuration, the Oracle Directory Integration Platform must change the DN values of all entries being mapped, including their references in group entries.

This requires more intensive computation.

If you synchronize in this way, you need to use the dnconvert mapping rule as described in "Supported Attribute Mapping Rules and Examples" on page 6-10.

16.1.3.3 Example: Integration with a Single Third-Party Directory Domain

Figure 16–2 shows an example of one-to-one mapping between Oracle Internet Directory and a third-party directory.

Figure 16–2 Default DIT Structures in Oracle Internet Directory and a Third-Party Directory When Both Directory Hosts Are Under the Domain us.MyCompany.com

In the one-to-one mapping illustrated in Figure 16–2:

See Also: The section "Choose the Structure of the Directory Information Tree" on page 16-16 for more information about planning the directory information tree

Oracle Internet Directory

user_2

user_1 user_3 user_N

users dc=us dc=MyCompany dc=com [Root DSE]

Third-Party Directory

user_2

user_1 user_3 user_N

users

us.MyCompany.com

Planning Your Integration Environment

■ Both Oracle Internet Directory and the third-party directory hosts have the same topology.

■ Users are synchronized only from the third-party directory to Oracle Internet Directory. All users to be synchronized are stored in one container in the third-party directory, in this case users.us.MyCompany.com.

■ The same DIT structure is maintained in both the third-party directory and Oracle Internet Directory. All users appear in the same users subtree identified by the value cn=users,dc=us,dc=MyCompany,dc=com.

In the example shown in Figure 16–2, only the users subtree must be synchronized from the third-party directory to Oracle Internet Directory using one-to-one domain mappings.