Understanding the Directory Tier

Enterprise Deployment Overview 1-9

1.5.1 Understanding the Directory Tier

The directory tier is in the Intranet Zone. The directory tier is the deployment tier where all the LDAP services reside. This tier includes products such as Oracle Internet Directory and Oracle Virtual Directory. The directory tier is managed by directory administrators providing enterprise LDAP service support. The directory tier is closely tied with the data tier. Access to the data tier is important for the following reasons: ■ Oracle Internet Directory relies on Oracle Database as its back end. ■ Oracle Virtual Directory provides virtualization support for other LDAP services or databases or both. In some cases, the directory tier and data tier might be managed by the same group of administrators. In many enterprises, however, database administrators own the data tier while directory administrators own the directory tier. Typically protected by firewalls, applications above the directory tier access LDAP services through a designated LDAP host port. The standard LDAP port is 389 for the non-SSL port and 636 for the SSL port. LDAP services are often used for white pages lookup by clients such as email clients in the intranet. The directory tier stores two types of information: ■ Identity Information: Information about users and groups ■ Oracle Platform Security Services OPSS: Information about security policies and about configuration. You must always store policy information in Oracle Internet Directory. You may store identity information in Oracle Internet Directory or in another directory such as Microsoft Active Directory. If you store the Identity details in a non-OID directory you can either use Oracle Virtual Directory to present that information or use Oracle Directory Integration Platform to synchronize the users and groups from the non-OID directory to Oracle Internet Directory. A split directory configuration is one where identity data is stored in multiple directories, possibly in different locations. Use this kind of deployment when you do not want to modify the existing Identity Store by extending the schema. In that case, deploy a new Oracle Internet Directory or ODSEE instance to store the extended attributes. Alternatively, you can use the Oracle Internet Directory instance deployed for Policy Store for this purpose. In this scenario, use Oracle Virtual Directory to present all the identity data in a single consolidated view that Oracle Identity Management components can interpret. Although you can use a single Oracle Internet Directory instance for storing both the identity and policy information, in some cases it might be required that you use two separate Oracle Internet Directory installations - one for the Policy Store and another for Identity Store. Examples include the following scenarios: ■ The throughput or enterprise directory requirements dictate separating out the two stores See Also: Configuring an Identity Store with Multiple Directories in Oracle Fusion Middleware Integration Overview for Oracle Identity Management Suite for information about configuring Oracle Virtual Directory in a split directory environment. 1-10 Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management If you intend to separate your identity and policy information, you must create two separate clusters of highly available Oracle Internet Directory. These Oracle Internet Directory clusters can share the same machines but they should use separate Real Application Clusters databases as their data store. If you are using Oracle Internet Directory exclusively, you do not need to use Oracle Virtual Directory. This guide assumes that you are creating two virtual names: one for your Policy Store policystore.mycompany.com and one for your Identity Store idstore.mycompany.com. When using a single Oracle Internet Directory for both your identity and policy information, you can either create two virtual host names, both pointing to the same directory, or combine them into a single suitable virtual host name in the load balancer.

1.5.2 Understanding the Application Tier