Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Internet Directory
11g Release 1 (11.1.1)

Part Number E10029-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

5 Understanding Oracle Internet Directory Organization

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

5.1 The Directory Information Tree

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

Figure 5-1 shows a directory information tree for a hypothetical company, called MyCompany, that is deploying identity management.

Figure 5-1 Planning the Directory Information Tree

This illustration is described in the text.

MyCompany makes the following decisions with respect to the logical organization of the directory in their U.S. deployment:

Planning the logical organization of the directory for Oracle Identity Management involves planning:

5.2 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:

5.3 Planning the Names and Organization of Users and Groups

This section offers some things to consider when modeling users and groups in Oracle Internet Directory. 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.

5.3.1 Organizing 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 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 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.

  • The default attribute for uniquely identifying users is cn or CommonName. The typical value of CommonName is the person's full name. People's names or email addresses, however, can change and therefore might not be suitable as values of this attribute. If possible, choose a value that will not change and that uniquely identifies a user, such as the employee id.

  • 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 in Oracle Internet Directory with the one used in the third-party directory. This simplifies the synchronization and 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.

5.3.2 Organizing 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 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 attribute 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.

5.4 Migrating a DIT from a Third-Party Directory

To migrate a DIT from a third-party directory, use the techniques described in Chapter 37, "Migrating Data from Other Data Repositories" and in Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform for synchronizing with third-party metadirectory solutions and integrating with third-party directories. If you are migrating a DIT from a Microsoft Active Directory environment, also see the chapter on integration with the Microsoft Active Directory Environment. Oracle recommends that you configure the Oracle Internet Directory DIT to be identical to the third-party DIT.