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 how they work in association. This section describes the following topics:

• Working of Oracle Unified Directory

• Network Groups

• Workflows

• Workflow Element

Working of Oracle Unified Directory

As illustrated in Figure 1-2, a client request is managed by Oracle Unified Directory before being forwarded to the data source.

A client request pursues the following path:

1. The request is attached to a network group based on the criteria and a QOS policy is assigned.

2. The network group forwards the request to a workflow, which defines the naming context.

3. The workflow forwards the request to a workflow element, which defines the how the data request will be treated. That is, if it will go through distribution or load balancing.

4. Once it has gone through the distribution or load balancing flow, the request is sent to the data source.

Figure 1-1 Distribution Diagram

Figure 1-2 High Level Presentation of Oracle Unified Directory Components

Network Groups

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

The network groups handle all client interactions and dispatch them to workflows, based on:

• Criteria

  Criteria can include security authentication level, port number, client IP mask, client bind DN, 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.

Within Oracle Unified Directory, you can have more than one network group defined, each with different properties and different priorities. However, the 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 a client 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 1-3, 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 1-3 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 of workflows, see Workflows. However, 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. You will get an error message indicating the QOS policy that causes an error.

In addition, if a network group does not have any workflows attached to it, your request will not be treated. You will get an error message indicating: No such entry.

For information on managing network groups, see Configuring Network Groups With dsconfig in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.

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

For example, if a Oracle Unified Directory has the following network groups:

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

  This network group is associated to 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 to Workflow 2, with naming context dc=test,dc=com

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

Example 1-2 Using Network Group QOS Policy to Filter Requests

For example, if a Oracle Unified Directory has 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.

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 when the naming context 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 1-3 A Network Group Routing to Several Workflows

For example, if a Oracle Unified Directory has the following network groups (as illustrated in Figure 1-3), 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=sun,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=sun,dc=com would be handled by Network Group 2 and sent to Workflow 2.

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

Workflow Element

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

Within the Oracle Unified Directory there are different types of workflow elements:

• Load Balancing workflow elements.

• Distribution workflow elements.

• Proxy workflow elements.

• DN renaming workflow elements.

For a proxy server, workflow elements can have different roles:

• The load balancing and distribution workflow elements act as a pointer, routing the request along one path.

• The proxy workflow element is a direct access to the data source.

• The DN renaming workflow element transforms the entries DN and DN type attributes.

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

Figure 1-4 Client Request for a Directory Server

Moreover, Oracle Unified Directory has a number of built-in workflow elements. These should not be modified or deleted.