5 Understanding Oracle Unified Directory Concepts and Architecture
The following topics provide conceptual descriptions of the basic components of Oracle Unified Directoryand discusses Oracle Unified Directory architecture:
5.1 Understanding Oracle Unified Directory Components
Oracle Unified Directory integrates three key components: Network Groups, Workflows, and Workflow Elements. It is imperative to understand the role of each component to gain insight into the complete functionality of the product.
This section provides an overview of each component and contains the following topics:
5.1.1 Understanding Network Groups
Network groups are the entry point of all client requests handled by Oracle Unified Directory.
Network groups are described in the following topics:
5.1.1.1 About Network Groups
Network groups handle all client interactions and dispatch them to local back end workflow or proxy workflow based on some norms. You need to understand those standards to define a robust configuration.
The network groups makes use of the following standards to handle client interactions:
-
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 5-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.
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 Understanding 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 Configuring Network Groups Using dsconfig.
5.1.1.2 Using Network Group Criteria to Route to Different Workflows
To use the network group criteria to route different workflows, perform the steps described in this section.
Assume an Oracle Unified Directory configuration with the following network groups:
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, then 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.
5.1.1.3 Using Network Group QOS Policy to Filter Requests
To use the network group QOS policy set to filter requests, perform the steps described in this section.
Assume an Oracle Unified Directory configuration with the following network groups:
Therefore, if the bind DN is dc=example,dc=com, then 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.
5.1.2 Understanding Workflows
A workflow represents the flow of data. It comprises workflow elements and their associated connections.
A workflow is defined by a naming context (base DN) and a workflow element that defines 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.
To learn more about workflow, you must review the following topics:
5.1.2.1 About Workflows
A workflow is the link between the network group and the naming context (suffixes). It defines the naming context that will be accessible for a given network group, when handling a request to a load balancing or distribution configuration.
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.
Each workflow is associated with an access control group, which defines the list of ACIs that apply to operations handled by this workflow. By default, an access control group known as Local Backends, exists. This access control group contains all ACIs coming from user data. You cannot delete it. You can also add virtual ACIs in this group, which implies that you must specify Local Backends as the access control group for the workflow for which virtual ACIs are disabled. You can specify any access control group for the workflow where virtual ACIs are enabled. For more information about ACIs, see Understanding Access Control Model in Oracle Unified Directory.
5.1.2.2 Using Network Groups to Route to Different Workflows
Use network groups to route to several different workflows.
Assume an Oracle Unified Directory configuration with the following network groups (as illustrated in Figure 5-1), where:
-
Network Group 1with a bind DN of**,l=fr,dc=example,dc=comThis network group is associated to
Workflow 1, with naming contextl=fr,dc=example,dc=com -
Network Group 2with a bind DN of**,l=uk,dc=example,dc=comThis network group is associated to
Workflow 2, with naming contextl=uk,dc=example,dc=com -
Network Group 3with a bind DN of**,dc=example,dc=comThis network group is associated to
Workflow 1andWorkflow 2, with naming contextdc=example,dc=com
A search with bind DN **,l=uk,dc=example,dc=com would be handled by Network Group 2 and sent to Workflow 2.
A search with bind DN **,dc=example,dc=com would be handled by Network Group 3 and sent to Workflow 1 and Workflow 2.
5.1.3 Understanding Workflow Elements
Workflow elements are part of a routing structure. Each workflow contains at least one workflow element.
Oracle Unified Directory supports several different types of workflow elements:
-
Leaf workflow elements: This type comprises the Local Backend workflow elements and proxy workflow elements.
-
Routing workflow elements: This type comprises the load balancing workflow elements and distribution workflow elements.
-
Virtual workflow element: This type comprises the DN renaming workflow elements, RDN changing workflow elements, and Transformation workflow elements.
-
EUS workflow element: This type comprises the Enterprise User Security (EUS) workflow elements.
-
EUS context workflow element: This type comprises the EUS context workflow elements.
-
LDIF workflow element: This type comprises the LDIF Local Backend workflow elements.
-
Memory backend workflow element: This type comprises the memory local backend workflow elements.
For a directory server, the workflow element is the DB Local Backend, as illustrated in Figure 5-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 5-2 Client Request for a Directory Server
Oracle Unified Directory has several preconfigured workflow elements that should not be modified or deleted.
5.2 Overview of Oracle Unified Directory Architecture
Oracle Unified Directory is a Java-based directory service that provides storage, synchronization, proxy, and virtualization features. The unified solution provides architecture flexibility and optimization, enhances application deployments, and reduces total cost of ownership.
The example in this section illustrates how the components of Oracle Unified Directory work together to provide a comprehensive solution to the industry.
As illustrated in Figure 5-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:
-
The request handlers place the incoming LDAP requests in the work queue from where the worker thread grabs them.
-
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.
-
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.
-
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.
-
-
After the request has gone through the assigned processing, the request is sent to the data source.
Figure 5-3 High-Level Presentation of Oracle Unified Directory Components
