4 Understanding Oracle Unified Directory Concepts and Architecture

Oracle Unified Directory is a next-generation unified directory solution that integrates storage, synchronization, and proxy functionality to help you manage the critical identity information that drives your business applications. These capabilities enable you to meet the evolving needs of an enterprise architecture.

This chapter provides conceptual descriptions of the basic components of Oracle Unified Directory and discusses Oracle Unified Directory architecture. This chapter covers the following topics:

• Section 4.1, "Oracle Unified Directory Components"

• Section 4.2, "Architecture of Oracle Unified Directory"

4.1 Oracle Unified Directory Components

Oracle Unified Directory integrates three key components: Network Groups, Workflows, and Workflow Elements. This section provides an overview of each component and contains the following topics:

• Section 4.1.1, "Network Groups"

• Section 4.1.2, "Workflows"

• Section 4.1.3, "Workflow Elements"

4.1.1 Network Groups

Network groups are the entry point of all client requests handled by Oracle Unified Directory.

Network groups handle all client interactions and dispatch them to local backend workflows or proxy workflows, based on:

• Criteria

  Criteria can include security authentication level, port number, client IP mask, client bind DN, bind ID, domain name, and other criteria.

• Quality of Service (QoS) policies

  QoS policies can include LDAP referral policy, request filtering, client connection affinity, and resource limits.

You can define more than one network group, each with different properties and different priorities. However, an incoming client connection can only be attached to one network group at a time. An incoming client connection is attached to the first network group for which the connection complies with the criteria defined for that network group.

The client connection is assessed by each network group, in order of priority, until it complies with all the criteria of that network group. As illustrated in Figure 4-1, the request is first sent to the network group with the highest priority: Network Group 1. Network Group 1 assesses if the request matches all the required criteria. If it does not match all of the criteria, it forwards the request to the next network group in the list: Network Group 2.

If the request matches all the properties of a network group, the network group assesses if the client connection matches the QoS policies of that network group. If it matches the QoS policies, it is routed to the associated workflow.

Figure 4-1 Network Group Selection

Description of "Figure 4-1 Network Group Selection"

A network group can be associated with one or more workflows, each workflow corresponding to a different naming context. For more information about workflows, see Section 4.1.2, "Workflows". If the client connection matches the criteria of a network group, but not the QoS policies of that network group, the connection is not forwarded to the workflow, nor is it sent to the next network group. Instead, an error is returned, indicating the QoS policy that caused the error.

If a network group has no workflows attached to it, the request is not handled. Instead, the server returns an error message of the sort: No such entry.

For information about managing network groups, see Section 14.1.6, "Configuring Network Groups With dsconfig".

Example 4-1 Using Network Group Criteria to Route to Different Workflows

Assume an Oracle Unified Directory configuration with the following network groups:

• Network Group 1: criteria set with bind DN **,dc=example,dc=com

  This network group is associated with Workflow 1, with naming context dc=example,dc=com

• Network Group 2: criteria set with bind DN **,dc=test,dc=com

  This network group is associated with Workflow 2, with naming context dc=test,dc=com

Depending on the bind DN, a search would be routed through Network Group 1 or Network Group 2. For example, if the bind DN was uid=user.1,dc=test,dc=com, the request would not be accepted by Network Group 1, but would be forwarded to and accepted by Network Group 2, and forwarded to Workflow 2.

Example 4-2 Using a Network Group QOS Policy to Filter Requests

Assume an Oracle Unified Directory configuration with the following network groups:

• Network Group 1: criteria set with bind DN **,ou=admin,dc=example,dc=com

  QoS policy set with resource limits size limit=0, time limit=0. Therefore, for admin group, there are no limits.

  This network group is associated to Workflow 1, with naming context dc=example,dc=com.

• Network Group 2: criteria set with bind DN **,dc=example,dc=com

  QoS policy set with resource limits size limit=100, time limit=30 s. Therefore, for all connections other than admin group, there are limits set on the resources used.

  This network group is also associated to Workflow 1, with naming context dc=example,dc=com.

Therefore, as long as the bind DN is dc=example,dc=com, the requests will be forwarded to Workflow 1. The QoS policy set for Network Group 2 gives restricted access to Workflow 1, for anyone that is not admin. Anyone who binds as admin will access Workflow 1 through Network Group 1, and will have no limitations on resource limits.

4.1.2 Workflows

A workflow is defined by a naming context (base DN) and a workflow element that define how Oracle Unified Directory should handle an incoming request. A workflow must be registered with at least one network group, but can be attached to several network groups.

A network group can point to several workflows if the naming contexts of the workflows are different. However, several network groups can point to the same workflow when the network group QoS policies are different, but the naming context of the workflow is the same.

Example 4-3 A Network Group Routing to Several Workflows

Assume an Oracle Unified Directory configuration with the following network groups (as illustrated in Figure 4-1), where:

• Network Group 1 with a bind DN of **,l=fr,dc=example,dc=com

  This network group is associated to Workflow 1, with naming context l=fr,dc=oracle,dc=com

• Network Group 2 with a bind DN of **,l=uk,dc=example,dc=com

  This network group is associated to Workflow 2, with naming context l=uk,dc=example,dc=com

• Network Group 3 with a bind DN of **,dc=example,dc=com

  This network group is associated to Workflow 1 and Workflow 2, with naming context dc=example,dc=com

A search with bind DN **,l=uk,dc=oracle,dc=com would be handled by Network Group 2 and sent to Workflow 2.

A search with bind DN **,dc=oracle,dc=com would be handled by Network Group 3 and sent to Workflow 1 and Workflow 2.

4.1.3 Workflow Elements

Each workflow contains at least one workflow element. Workflow elements are part of a routing structure.

Oracle Unified Directory supports several different types of workflow elements:

• Leaf workflow elements: This comprises the local backend workflow elements and proxy workflow elements.

• Routing workflow elements: This comprises the load balancing workflow elements and distribution workflow elements.

• Virtual workflow element: This comprises the DN renaming workflow elements, RDN changing workflow elements, and Transformation workflow elements.

• EUS workflow element: This comprises the Enterprise User Security (EUS) workflow elements.

• EUS context workflow element: This comprises the EUS context workflow elements.

• LDIF workflow element: This comprises the LDIF local backend workflow elements.

• Memory backend workflow element: This comprises the memory local backend workflow elements.

For a directory server, the workflow element is the DB local backend, as illustrated in Figure 4-2.

For a proxy server, the workflow elements can be chained with load balancing workflow elements or distribution workflow elements that act as a pointer, routing the request along a specific path. The proxy workflow element provides direct access to the remote data source.

Figure 4-2 Client Request for a Directory Server

Description of "Figure 4-2 Client Request for a Directory Server"

Oracle Unified Directory has a number of preconfigured workflow elements that should not be modified or deleted.

4.2 Architecture of Oracle Unified Directory

This section presents the high-level architecture of Oracle Unified Directory.

As illustrated in Figure 4-3, a client request is managed by Oracle Unified Directory before being forwarded to the data source. In this scenario, there are three network groups, such as ng1, ng2, and ng3. The first network group ng1 contains two workflows while ng3 contains a single workflow. A workflow is defined by a suffix. The suffix for w1 is ou=X and a workflow points to a tree of workflow elements. The tree of workflow elements determines the processing to apply on an operation.

A client request pursues the following path:

1. The request handlers place the incoming LDAP requests in the work queue from where the worker thread grabs them.

2. The operation is routed to a network group based on the network group criteria assigned. An operation must comply with the network group QoS policies regardless of the server profile, directory server or proxy server.

3. The network group forwards the operation to a workflow, which defines the naming context. The determination of the workflow is based on the match between the request base DN and the workflow naming context.

4. The workflow forwards the operation to its tree of workflow elements, which defines how to treat the request. The content of the tree of workflow elements depends on the server profile as follows:

   • For a directory server, you can only configure the workflow element as the local backend workflow element (a storage).

   • For a proxy server, you can configure the workflow element as a distribution workflow element, a load balancing workflow element, a DN renaming workflow element, or an LDAP proxy workflow element.

5. After the request has gone through the assigned processing, the request is sent to the data source.

Figure 4-3 High-Level Presentation of Oracle Unified Directory Components

Description of "Figure 4-3 High-Level Presentation of Oracle Unified Directory Components"