Planning the Directory Information Tree for Identity Management

Oracle Internet Directory serves as a shared repository for the entire Oracle Identity Management infrastructure. A carefully planned logical structure of the directory enables:

• Enforcement of security policies that meet the requirements of your deployment

• A more efficient physical deployment of the directory service

• Easier configuration of synchronization of a third-party directory with Oracle Internet Directory

Planning the logical organization of the directory for Oracle Identity Management comprises:

• Planning the overall structure of the directory information tree (DIT)

• Planning the directory containment and naming for users and groups

• Planning the identity management realm

Figure 19-4 shows the impact of each of these steps in the directory information tree.

Figure 19-4 Planning the Directory Information Tree

Text description of the illustration oidag120.gif

Figure 19-4 illustrates a hypothetical company, called Acme, that makes the following decisions with respect to the logical organization of the directory in their U.S. deployment:

• A domain name-based scheme is to represent the overall DIT hierarchy. Because the identity management infrastructure is being rolled out in the us domain, the root of the DIT is dc=us,dc=acme,dc=com.

• Within the naming context chosen, all users are represented under a container called cn=users. Within this container, all users are represented at the same level--that is, there is no organization-based hierarchy. In addition, the uid attribute is chosen as the unique identifier for all users.

• Within the naming context chosen, all enterprise groups are represented under a container called cn=groups. Within this container, all enterprise groups are represented at the same level. The naming attribute for all group entries is cn.

• Finally, the container dc=us is chosen as the root of the identity management realm. In this case, the name of the realm is us. The deployment expects to enforce similar security policies for all users who fall under the scope of the us realm.

This section discusses further details to consider when designing the logical organization of directory information. It contains these topics:

• Planning the Overall Directory Structure

• Planning the Names and Containment of Users and Groups

• Planning the Identity Management Realm

Planning the Overall Directory Structure

This task involves designing the basic directory information tree that all identity management-integrated applications in the enterprise are to use. As you do this, keep these considerations in mind:

• The directory organization should facilitate clean and effective access control. If replication--either full or partial--is planned, then proper boundaries and policies for directory replication can be enforced only if the design of the DIT brings out the separation.

• If the enterprise is integrating with a third-party directory server, then it is best to align the DIT design of Oracle Internet Directory with the existing DIT. This consideration also applies to deployments that are rolling out Oracle Internet Directory now but plan to roll out another directory later--for example, Microsoft Active Directory that is required for the operation of software from Microsoft. In each case, choosing an Oracle Internet Directory DIT design that is more consistent with that of the third-party directory makes management of user and group objects easier through Oracle Delegated Administration Services and other middle-tier applications.

• In a single enterprise scenario, choosing a DIT design that aligns with the DNS domain name of the enterprise suffices. For example, if Oracle Internet Directory is set up in a company having the domain name acme.com, then a directory structure that has dc=acme,dc=com is recommended. Oracle Corporation recommends that you not use departmental or organization level domain components such as engineering in engineering.acme.com.

• If the enterprise has an X.500 directory service, and no other third-party LDAP directories in production, then it may benefit by choosing a country-based DIT design. For example, a DIT design with the root of o=acme, c=US might be more suitable for enterprises which already have an X.500 directory service.

• Because the directory can be used by several applications--both from Oracle and from third-parties alike--the naming attributes used in relative distinguished names (RDNs) constituting the overall DIT structure should be restricted to well-known attributes. The following attributes are generally well-known among most directory-enabled applications:
  • c: The name of a country

  • dc: A component of a DNS domain name

  • l: The name of a locality, such as a city, county or other geographic region

  • o: The name of an organization

  • ou: The name of an organizational unit

  • st: The name of a state or province

• A common mistake is to design the DIT to reflect either the corporate divisional or organizational structure. Because most corporations undergo frequent reorganization and divisional restructuring, this is not advisable. It is important to insulate the corporate directory from organizational changes as much as possible.

Planning the Names and Containment of Users and Groups

Most of the design considerations that are applicable to the overall DIT design are also applicable to the naming and containment of users and groups. This section offers some additional things to consider when modeling users and groups in Oracle Internet Directory.

Considerations for Users

The Oracle Identity Management infrastructure uses Oracle Internet Directory as the repository for all user identities. Even though a user might have account access to multiple applications in the enterprise, there is only one entry in Oracle Internet Directory representing that user's identity. The location and content of these entries in the overall DIT must be planned before deploying Oracle Internet Directory and other components of the Oracle Identity Management infrastructure.

• As mentioned in the previous section, it is tempting to organize users according to their current departmental affiliations and hierarchy. However, this is not advisable because most corporations undergo frequent reorganization and divisional restructuring. It is more manageable to capture a person's organizational information as an attribute of that person's directory entry.

• There are no performance benefits derived from organizing users in a hierarchy according to organizational affiliations or management chain. Oracle Corporation recommends that you keep the DIT containing users as flat as possible.

• If the deployment has different user populations with each one maintained and managed by a different organization, then Oracle Corporation recommends subdividing users into containers based on these administrative boundaries. This simplifies the setting of access controls and helps in cases where replication is needed.

• The out-of-the-box default nickname attribute for uniquely identifying users in lookup operations is uid. This is the default attribute used for logins. The out-of-the-box default naming attribute for constructing a DN is cn.

• Typically, most enterprises have a Human Resources department that establishes rules for assigning unique names and numbers for employees. When choosing a unique naming component for directory entries, it is good to exploit this administrative infrastructure and use its policies.

• It is required that all user entries created in the directory belong to the following object classes: inetOrgPerson, orclUserV2.

• If you already have a third-party directory, or plan to integrate with one in the future, then it is beneficial to align the user naming and directory containment subsequent administration of the distributed directories.

  Note: In Oracle Internet Directory Release 9.0.2, the default value for the nickname attribute was cn. As of Release 9.0.4, the default value for this attribute is uid.

Considerations for Groups

Some applications integrated with the Oracle Identity Management infrastructure can also base their authorizations on enterprise-wide groups created by the deployment in Oracle Internet Directory. Like user entries, the location and content of these group entries should also be carefully planned. When you design groups, consider the following:

• There are no performance benefits to be gained from organizing enterprise groups in a hierarchy based on the organizational affiliations or ownership. Oracle Corporation recommends keeping the DIT that contains groups as flat as possible. This facilitates easy discovery of groups by all applications and fosters sharing of these groups across applications.

• It is preferable to separate the users and groups in the DIT so that different management policies can be applied to each set of entries.

• The attribute used to uniquely identify a group should be cn or CommonName.

• All group entries created by the enterprise in the directory should belong to the following object classes: groupOfUniqueNames and orclGroup. The former object class is an internet standard for representing groups. The latter is useful when using the Oracle Internet Directory Self-Service Console to manage groups.

• Instead of creating new directory access controls for each enterprise-wide group, consider doing the following:
  1. Use the owner attribute of the group to list which users own this group.

  2. Create an access control policy at a higher level that grants all users listed in the owner attribute special privileges to perform the various operations.

• In the description attribute, provide information for users to understand the purpose of the group.

• Consider using the displayName attribute from the orclGroup object class. This enables Oracle Delegated Administration Services and Oracle Internet Directory Self-Service Console to display a more readable name for the group.

• If you have different sets of groups, each of which is maintained and managed by a different organization with its own administrative policies, then sub-divide the groups into containers based on these administrative boundaries. This simplifies the setting of access controls. It also helps when replication is needed.

• If you already have a third-party directory, or plan to integrate with one in the future, then align the group naming and directory containment in Oracle Internet Directory with the one used in the third-party directory. This simplifies the synchronization and subsequent administration of the distributed directories.

Planning the Identity Management Realm

The previous sections describe guidelines for you to structure the overall DIT and the placement of users and groups for your deployment. Because implementing these guidelines can lead to an infinite number of deployment configurations, you need to capture the intent of your deployment in metadata in the directory itself. This metadata enables Oracle software and other third-party software relying on the Oracle Identity Management infrastructure to understand the deployment intent and successfully function in customized environments.

In Oracle Internet Directory, this deployment intent is captured in the identity management realm. The realm also helps set identity management policies for users and groups whose placement is described in the previous section.

The identity management realm is a well-scoped area in the directory that consists of:

• A well-scoped collection of enterprise identities--for example, all employees in the US)

• A collection of identity management policies associated with these identities

• A collection of groups--that is, aggregations of identities--that makes it easier to set identity management policies

Once you have decided on the overall DIT structure and the placement of users and groups, you need to identify the directory entry to serve as the root of the identity management realm. This entry determines the scope of the identity management policies defined in the realm. By default, the scope is the entire directory subtree under the root of the identity management realm. Under this entry, a special entry called OracleContext is created. It contains the following:

• The deployment-specific DIT design, including user and group naming and placement, as described in previous sections

• The identity management policies associated with this realm

• Additional realm-specific information specific to Oracle applications

When planning the identity management realm, consider the following:

• The security needs of your enterprise must dictate the choice of the root of the identity management realm. Typically, most enterprises need only one realm. However, multiple realms may be required when multiple user populations are managed with different identity management policies.

• If you already have a third-party directory, or plan to integrate with one in the future, then align the choice of the identity management realm root with the DIT design of the third-party directory. This simplifies the synchronization and subsequent administration of the distributed directories.

• To configure and administer identity management realms, use the administrative tools provided by Oracle Internet Directory. These include the the Oracle Internet Directory Self-Service Console and command-line tools.

• Once you have used the Oracle Internet Directory tools to configure the identity management realm, plan on updating the directory naming and containment policies to reflect the customizations made by the deployment. This update must happen prior to installing and using other Oracle components that use the Oracle Identity Management infrastructure.

Figure 19-5 shows an example of an identity management realm for an enterprise called Acme.

Figure 19-5 Example of an Identity Management Realm

Text description of the illustration oidag119.gif

In the example in Figure 19-5, the deployment has chosen to use a domain name-based DIT structure. In this case, the container dc=us,dc=acme,dc=com is chosen as the root of the identity management realm. This results in the creation of a new identity management realm whose scope, by default, is restricted to the entire directory subtree under the entry dc=us. The name of the identity management realm is US.