14 Understanding Oracle Unified Directory Virtualization

For most enterprises, user identity information such as user profiles, access and authorization data for a single entry is scattered across heterogeneous data sources at multiple locations. For instance, employee information is stored in HR databases or Microsoft Active Directories, customer and partner data in CRM databases and additional LDAP directories. Companies require aggregated data of the user from various data sources in real time. As a consequence, application-specific directories proliferate, copying and synchronizing identity data. This in turn, leads to high administration and maintenance cost, inconsistent identity data, and compliance issues.

Oracle Unified Directory provides a directory service solution that addresses these challenges. Oracle Unified Directory now offers support for the Join workflow element that presents a virtual directory view of the repositories and then routes data to and from the repositories.

Oracle Unified Directory defines workflow elements, like the Proxy workflow element to connect to its underlying data repositories. You can also combine data from different workflow elements to present a customized directory tree using the Join workflow element. The Join workflow element combines data from multiple data sources on the fly. That is to say, it is dynamic and does not require synchronization between its data sources. It consolidates identity data without moving data from its native locations, and reuses identity data without copying. This leads to ease of deployment, diminishes costs, provides a simplified identity infrastructure, and a high return on investment by eliminating the need to constantly adapt the applications from changes in the identity stores.

Note:

You must keep in mind that Directory virtualization is not running a directory server in a virtualized environment.

The sections in this chapter describe this virtualization workflow element in detail, and contains the following topics:

14.1 Understanding Join Workflow Element

There are scenarios where data for a single entry is split across two or more data sources, and the client requires aggregated data of the user from various sources in real time.

The Join workflow element combines two or more different data sources into one unified LDAP view similar to a relational database's table join. The Join workflow element does not connect to the underlying data repository. It builds on top of one or more proxy sources or local backends to assemble its data on the fly. That is to say, it is dynamic and performs no synchronization between proxied sources. You can think of the Join workflow element as joining two or more data repositories by defining join relationships, also known as Joiners, between workflow elements. You can configure as many workflow elements as needed.

The main objective of a Join workflow element is to present merged data to an LDAP client in real time. A Join workflow element solves the problem of split profiles, where identity data for a single entry is stored in multiple directories. For example, a Join workflow element is used to link a person's LDAP entry with their job title from the Human Resources database.

14.2 Features of Join Workflow Element

The following is a list of Join workflow element capabilities:

  • Join workflow element combines data from multiple Join participants on the fly. That is to say, it is dynamic and performs no synchronization between its sources.

  • Allows you to merge attributes and objectclasses from multiple participants to form a new virtual entry.

  • Support for sophisticated relationship tree among Join participants using complex Join rules.

  • Allows you to define relationship between any two participating elements. Support for one primary participant and any number of secondary participants.

  • For each entry retrieved from one participating element, the Join workflow element adds an attribute value, joinedentrydn that indicates which entries from secondary participants were used to form the consolidated entry.

  • For each entry retrieved from Primary participant, the Join workflow element queries all the associated secondary participants to form the combined entry.

  • Allows you to specify the attributes that can be retrieved and the attributes that can be stored in a participating data source. For more information, see Section 14.8, "Handling Attribute Flow Settings."

  • Support for operations that are set as enabled. For more information, see Section 14.12, "Managing Operations that are Enabled."

  • Support for bind-fall through feature. For more information, see Section 14.9, "Handling Bind Operations."

  • Allows you to cascade write operations. For more information, see Section 14.13, "Handling Cascading Write Operations to Secondary Participants."

  • Allows you to configure criticality of Join participants. For more information, see Section 14.11, "Determining the Criticality of Join Participants."

  • Support for different joiner types, such as one-to-one, many-to-one, and shadow for different kinds of Join scenarios. For more information, see Section 14.6, "Joiner Types."

  • Support for translation of DN-syntaxed attribute values from each repository suffix to a common Join workflow element suffix. For information, see Section 14.10, "Handling Translation of DN Attributes."

14.3 Understanding Join Participants

A Join participant is the workflow element, which contributes some information to Join workflow element to form the combined joined entry.

For example, you can configure a Join workflow element to aggregate user information, which is split between multiple directories. In this scenario, you need to create a proxy workflow element that is associated with a directory to retrieve information from that directory. After which, you need to formulate these workflow elements as the participants of a Join Workflow element.

A Join workflow element can have one or more participating data sources, each one exposed through a workflow element. The participating workflow elements can be a LDAP Proxy workflow element, Local Backend workflow element, Distribution workflow element, Load Balancing workflow element, or even another Join workflow element. Each participating workflow element is referred to as a Join participant.

Figure 14-1 depicts the relationship between a Join workflow element and the participating workflow elements.

Figure 14-1 Join Workflow Element and Join Participants

Description of Figure 14-1 follows
Description of ''Figure 14-1 Join Workflow Element and Join Participants''

A Join workflow element can have only one primary participant and zero or more secondary participants. The primary participant is used for creating and searching the directory tree entries. One of the participating workflow element is treated as the primary workflow element, whose Directory Information Tree (DIT) structure is exposed by Join workflow element by default. An entry must exist in the primary participant for it to be returned from a Join workflow element.

The Administrator determines the participant to be treated as Primary. The Join workflow element operates by taking each entry found in the primary participant and joining it with entries of other participants according to the defined Join rule.

Each participant has a suffix (a DN) associated with it. It has to be the same as backend naming context that is exposed through that participating workflow element or a descendant DN of it. The Join workflow element has a DN associated with it, which is the virtual DN exposed through the workflow to which the Join workflow element is associated with. Thus, the Administrator can configure the Join workflow element to restrict the view only to that Directory tree which is of interest to the client.

14.4 Join Rules

Join rules determine how an entry from one participant relates to an entry from another participant. It's imperative to specify Join rules, because if no Join rule is defined, the secondary participant is not queried during LDAP operations.

Note:

A Join rule always specifies the relationship between two participants only.

Join rules specify a join relationship between an entry in one participant and an entry in another participant. Join workflow element forms the search filter to search each secondary participant based on the Join rule defined for that secondary participant.

A Join workflow element has a Join rule configured for each secondary participant that specifies a relationship between entries in that participant with the other participant. The Join rule specified in at least one of the secondary participants should involve the primary participant, so that Join workflow element can traverse the entire relationship tree starting from the primary participant. Join rules have to be defined only in secondary participants and not in primary participant.

Join rules identify the attributes of an entry from one participant to search another participant for obtaining the matching entries. These matching entries are then joined with the original entry to form the joined entry. When a matching value is found in the destination view, a join between the two entries is created.

For each entry retrieved from one participating element, the Join workflow element adds an attribute value, joinedentrydn, which indicates the entries that were used to form the consolidated entry from the secondary participants. The Administrator decides the need to configure the Join workflow element to populate this attribute. It might be useful to troubleshoot Join issues.

Oracle Unified Directory provides two types of Join rules, LDAP filter Join rules and DN Join rules. All Join rules follow LDAP filter syntax. So, complex Join rules involving AND and OR is possible.

For example:

(&(P1.userId = P2.uid)(|(P1.deptNumber = P2.department)(P1.empNum = P2.empId)))

Note:

For shadow joiner, the Join rule should involve the same attribute in both primary and shadow participant. For example, p1.cn = p2.cn.

Join rules are always configured in the secondary participants and never in the primary participant. Following are examples of valid Join rules:

P2.commonName = P1.cn
P3.dn = P2.dn
(&(P4.cn= P3.cn)(P3.uid=P4.employeeid))
P1.uniquemember = P5.dn

Note, the order in which you define the Join rule does not matter. For example, P1.cn=P2.commonname is the same as P2.commonname=P1.cn.

The following sections briefly describe the two Join rules:

14.4.1 Attribute-based Join Rules

Attribute-based Join rules define a join relationship between two participants based on the common attribute values present in the matching entries from two participants.

For example, consider the following Join rule, p1.uid=p2.username where p1 and p2 are two Join participants. This Join rule indicates that for an entry in p1, a corresponding matching entry from p2 is retrieved and joined with the entry from p1, if the uid attribute value of an entry from p1 matches the username attribute value of an entry from p2. If uid is a multi-valued attribute in p1, then all the uid values are OR'ed while forming the search filter for querying p2. This implies, that the search filter sent to P2 is of the form:

(|(username=<uidvalue1>)(username=<uidvalue2>)) and so on

14.4.2 DN Join Rules

In some situations the participating data sources do not have any attribute values in common except the entry DN. In this case, the Administrator can configure the Join rule involving Entry DN.

A DN Join rule can take one of the following forms:

  • The entry DN in one participant matches an attribute in another participant. For example, you can configure this rule using the following syntax:

    P8.member = P7.dn

    The preceding DN Join rule stipulates that the member attribute value in P8 should be used for locating the matching entries from P7.

  • Entry DN in one participant is same as the entry DN in another participant. For example, you can configure this rule using the following syntax:

    P2.dn = P3.dn

    This Join rule stipulates that an entry DN in P2 should match an entry DN in P3 to form a joined entry. Note that in this case, portion of the DNs below the participant suffixes are considered for finding the matching entries, although the full DNs may differ. Consider for example, that the participant P2 has a suffix dc=primary and the participant P3 has a suffix dc=secondary. In this case, the aforesaid Join rule implies that the tree below the suffixes are identical. So, the entry "uid=user.1,cn=users,dc=secondary" would be associated with "uid=user.1,cn=users,dc=primary."

14.5 Join Workflow Element Configuration Model

Figure 14-2 illustrates the configuration model for Join workflow element and Join participants using Join rules.

Figure 14-2 Join Workflow Element Configuration Model

Description of Figure 14-2 follows
Description of ''Figure 14-2 Join Workflow Element Configuration Model''

Oracle Unified Directory treats all the participating elements equal. However, you just need to configure one participant as primary. In Figure 14-2, P1 is configured as the primary participant. It is not imperative to define a Join rule on a primary participant.

All other participants, P2 through P8 are secondary participants. Each secondary participant has a Join rule and a joiner type defined for its relationship with another participant. For example, in case of P2 the Join rule P2.cn=P1.cn defines its relationship with P1 and if the joiner type configured in P2 is many-to-one, then it implies that the relationship from P1 through P2 is one-to-many.

Participants P2, P8, and P5 are directly related to the primary participant P1, while the other secondary participants are indirectly related to the primary participant.

14.6 Joiner Types

A Joiner type defines the join relationship between two participants. Join relationship defines the way two Join participants are connected. In addition, a Join relationship between two participants is directed and defines the way a start participant is connected to the end participant. These Joiner types work for any kind of Join rule defined, complex or simple.

Note:

When a Join relationship from P1 to P2 with many-to-one Joiner type is configured, then internally Join workflow element implicitly creates a reverse relationship from P2 to P1 with one-to-many joiner type and vice-versa. For a one-to-one joiner and a shadow joiner, the reverse relationship also contains the same joiner type as that of the original relationship configured.

The following is a description of the supported joiner types, including:

14.6.1 One-to-One Joiner Type

The one-to-one joiner defines a one-to-one relationship between the entries in the two participants. In a one-to-one Joiner type, each entry in the start participant corresponds with one entry in the end participant of this relationship. If more than one matching entries exist in the end participant, then the Join workflow element uses the first returned entry from end participant for the Join.

You can specify a more complex Join criterion involving a combination of AND and OR conditions using the LDAP filter syntax for the Join criteria. For example:

( & (P1.userId = P2.uid) ( | (P1.deptNumber = P2.department) (P1.empNum = P2.empId) ) )

In the preceding scenario, the search filter used for the secondary participant is coined based on the complex Join criteria configured. If the entry from primary participant does not have all the primary attributes specified in the Join rule, then the Join is not formed.

Figure 14-3 shows a a high-level example of a one-to-one joiner used for authentication.

Figure 14-3 Sample One-to-One Joiner Type for Authentication

Description of Figure 14-3 follows
Description of ''Figure 14-3 Sample One-to-One Joiner Type for Authentication''

14.6.2 One-To-Many Joiner Type

In one-to-many Joiner type, if each entry in the start participant corresponds with more than one entry in the end participant of the relationship, then all the matching entries from end participant are taken into consideration while forming the virtual joined entry. There are situations where one entry in the start participant has multiple corresponding entries in the end participant. In such a scenario, you need to consolidate all these entries into one virtual entry. However, all matching entries in the end participant are included in the Join.

The one-to-many Join is useful if you have to consolidate multiple role objects or identities into one virtual entry.

Figure 14-4 depicts a scenario where a policy server makes policy decisions about an individual. For integration purposes, the policy server prefers to see a single entry with the rights of the user exposed as a privilege attribute, which allows the policy server to test rights assertions with queries such as:

ldapsearch -b "uid=e027451,ou=People,o=LargeCo" -s base "(priv=XYZ Mgr)"

Figure 14-4 One-To-Many Joiner Type

Description of Figure 14-4 follows
Description of ''Figure 14-4 One-To-Many Joiner Type''

The one-to-many joiner is used to match one or more privileges to a user based on a profile attribute in their main ou=People entry. The one-to-many joiner looks for all privileges with the same profile value as in the entry and merges them with the entry. A second stage Join uses the one-to-one so that the Oracle Directory Server Enterprise Edition (ODSEE) combined profile is used with the user's Active Directory credentials.

14.6.3 Many-To-One Joiner Type

The many-to-one Join relationship defines a many-to-one relationship between two participants. It is the inverse of one-to-many joiner type. There are situations where multiple entries in the start participant has a corresponding single entry in the end participant.

Imagine for example, consider a scenario where the primary participant contains the list of employee information and the secondary participant contains a list of department information. Multiple employees may belong to one department. Therefore, a single department number in the secondary participant might apply to more than one employee in the primary participant. If an employee is deleted from the primary participant, you do not want the employee's department to be deleted from the secondary participant. To address this cascading delete issue, you can configure a relationship from secondary participant to primary participant using a one-to-many Joiner type, so that the Join workflow element internally creates a many-to-one joiner relationship from primary participant to secondary participant. This means that deleting an entry in the primary participant does not result in the deletion of the shared entry in the secondary participant.

14.6.4 Shadow Joiner Type

The Shadow Joiner allows you to store entries in a source such as an LDAP or Database stores that requires a schema extension, but the schema extension is not possible either for business or technical reasons. The Shadow joiner allows you to store the extended attributes in another store such as Local Backend workflow element.

The Shadow Join relationship maintains the same structure of the entry in the primary participant, but stores additional attributes by creating shadow entries using a separate source. Using the Shadow Join relationship, applications can use the enterprise directory and also store application-specific attributes in the shadow directory such as Local Backend workflow element. The application believes it is communicating to a directory that stores all attributes, but Oracle Unified Directory silently stores application-specific data in an alternate shadow directory.

The Shadow Joiner works by encoding all primary participant DN's into a hash that is used to locate the matching entry in the shadow participant. When the Join workflow element fails to locate a corresponding record in the shadow participant, then it automatically creates a new one, storing the designated attributes in the shadow participant. The Shadow joiner type will operate transparently to the application, taking care of creating and renaming entries in sync with that of the primary workflow element.

The Shadow Join supports all LDAP operations. When an LDAP modify operation occurs, the Shadow Join examines the parameters identified by the shadow participant's storable attributes to see if any attributes to be stored in the secondary participant. If any such attributes exist, the Shadow Join attempts to locate the local entry by taking the hash of the primary entry and locating the local entry. After it is located, the appropriate LDAP modify operation is performed locally. If a local entry is not found, the Shadow Join attempts a secondary search, in case the primary DN changed, to locate the entry using a primary key. If no local entry is found, a new entry is automatically created.

Note:

For shadow joiner, the Join rule should involve the same attribute in both primary and shadow participant. For example, p1.cn = p2.cn.

You must ensure replication is configured for shadow backend to achieve high availability.

Figure 14-5 shows a firewall, for example CheckPoint, configured to connect to an Oracle Unified Directory. The Oracle Unified Directory uses Local Backend Database to maintain the firewall schema, allowing integration of the firewall into the corporate enterprise directory without requiring that the corporate enterprise directory schema be extended with application-specific data. Instead, by storing it in Oracle Unified Directory Local Backend database, the application-specific data can be managed by the team responsible for the firewall management.

Figure 14-5 Example Shadow Join Use for Storing Application-Specific Data Locally

Description of Figure 14-5 follows
Description of ''Figure 14-5 Example Shadow Join Use for Storing Application-Specific Data Locally''

14.7 Join Condition

Conditional Join is a mechanism to restrict the entries that must be joined and those entries that do not satisfy the condition are returned as is without any Join done on them. The Join condition is specified in the LDAP filter syntax. For example, if the Join condition objectclass=inetorgperson is defined in the Primary participant, then only user entries from Primary are joined with other participant entries. The non-user entries from Primary are returned without any Join.

You can configure the Join condition irrespective of whatever Joiner type is configured.

The Join condition is always evaluated with respect to the participant in which it is defined. In majority of situations, it is useful to define this Join condition only in the primary participant and not in other participants.

You can define a Join condition using any complex filter involving OR and AND. For example:

(&(employeenumber=101)(sn=Smith))

14.8 Handling Attribute Flow Settings

The participating data source has the privilege to specify the attributes that can be retrieved from it and the attributes that can be stored in it. To configure this privilege, you can configure the storable and retrievable attributes for each participating workflow element.

The storable and retrievable attributes control how attributes flow into and out of a Join participant. These settings enhance security by preventing information from being requested or returned to an unauthorized client. In addition, for Join workflow elements, the attribute flow settings control which attributes flow to which participant since multiple Join participants can contribute to the same virtual joined entry.

Note:

Unlike access controls, the attribute flow settings provide silent enforcement. This is to say that the settings simply filter the request without returning an error to the client. In a high security environment this silent enforcement prevents the client from knowing whether they are even allowed to see a particular attribute.

The following is a list of attribute flow settings. The following sections describe each setting in detail:

14.8.1 Retrievable Attributes

The retrievable attributes setting controls the attributes that are retrieved by the Join participant from the target directory. The retrievable attributes setting contributes to server performance and in some cases, security, since you can only retrieve the specified attributes from a proxied server during SEARCH and COMPARE operations

In addition, you can use the retrievable attributes setting to control attribute flow when using the Join workflow element. This is because, a Join workflow element joins entries from multiple participants, therefore you must restrict the attributes that come from participants.You must configure the retrievable attributes settings on each participant in the Join workflow element to restrict the flow of attributes from participants in the Join view.

To configure this setting, in the Retrievable Attributes field, you must specify an explicit list of attributes that may be retrieved from a Join participant. An empty list implies all attributes are retrievable, unless non-retrievable attributes are defined. A specific list in the Retrievable Attributes field indicates that only the listed attributes may be requested from the proxied directory.

You can retrieve an attribute, for example attribute A1 in the following scenarios:

  • If both retrievable and non-retrievable list is empty.

  • If retrievable list is empty, but non-retrievable list does not contain A1.

  • If retrievable list contains A1, but non-retrievable does not contain A1.

14.8.2 Non-Retrievable Attributes

The non-retrievable attributes setting controls those attributes that may not be retrieved by the participant from the target directory. An empty list implies that all the attributes can be retrieved.

14.8.3 Storable Attribute

The storable attributes setting controls those attributes that may be stored by the participant on the target directory. The storable attributes setting contributes to server performance and in some cases, security, since only specific attributes and their values are sent to the proxied server for ADD and MODIFY operations.

In addition, you can use the storable attributes setting to control attribute flow when using the Join workflow element. This is because, a Join workflow element joins entries from multiple participants, therefore you must restrict the attributes that flow to participating workflow elements.You must configure the storable attributes settings on each participant in the Join view to restrict the flow of attributes from participants in the Join view.

To configure this setting, in the Storable Attributes field, you must specify an explicit list of attributes that should go to the participating workflow element. An empty list implies all attributes are storable, unless non-storable attributes are defined. You can store an attribute in the following scenarios:

  • If both storable and non-storable list is empty.

  • If storable list is empty, but non-storable list does not contain that attribute.

  • If storable list contains that attribute, but non-storable does not contain that attribute.

14.8.4 Non-Storable Attributes

The non-storable attributes setting controls those attributes that cannot be modified.

14.9 Handling Bind Operations

Join workflow element supports user authentication against any of the participants. The bind fall-through feature of Join workflow element allows you to try password validation against more than one data source. This is because the user identities might exist in multiple directories, and passwords might be stored in any of the data sources. Therefore, you need to authenticate the user against more than one data source instead of just authenticating against single data source.

To use the bind feature, you must configure bind as an enabled operation in that participant. Each participant of a Join workflow element has a configuration parameter ds-cfg-bind-priority that determines the priority of the participant in processing the bind.

Join workflow element supports user authentication for all participants. Each participant is assigned a bind priority and the bind falls through all the bind participants in that order until a successful bind is achieved. A bind failure is returned only when all bind participants have failed to authenticate the user successfully.

The bind priority can be any positive integer that is greater than equal to zero. The priority decreases from 0 to higher integers. That is, the participant with least number is considered to have the highest bind priority and the one having next least number has the next higher bind priority and so on. Zero is the highest priority.

14.10 Handling Translation of DN Attributes

DN attributes is a list of attributes to be treated as DNs for which namespace translation is required, such as member, uniquemember, and manager. For example, when reading a group entry from a proxied directory, Join workflow element converts the DN for the group entry and the uniquemember or member attributes if these attributes are in the DN attributes list.

Note:

Translate only those attributes that are needed by the client application. Entering all possible DN attributes may not be necessary for an application.

14.11 Determining the Criticality of Join Participants

The criticality configuration determines the behavior of a Join workflow element when a search performed against a participant fails due to a host error. Criticality applies only to search requests. Write operations are always non-critical in all participants. Even, bind and compare operations are always non-critical in all participants, so that they can fall-through all eligible participants until a success is found.

You can configure criticality by setting the criticality flag of a Join participant. The criticality setting of a Join workflow element can be one of the following:

  • true

    This is the default setting and indicates that the participant is considered as critical. If a participant fails to return a result because of an operation error, then the Join workflow element causes the overall search operation to fail and returns a DSA Unavailable error to the client regardless of whether data was found in any other participant or not.

  • false

    This setting indicates to the Join workflow element that the failure to perform an operation in the participant is not critical to the overall result. A criticality setting of false tells the Join workflow element that the failure to perform an operation in a non critical participant, then the result is simply omitted from the overall LDAP search results and Join workflow element returns partial results from any other participant and does not indicate any error.

  • Partial

    This setting indicates that the participant is partially critical. This implies that the application can notify its own users that partial results were obtained. If a partially-critical participant fails to return a result because of an operation error, then the Join workflow element returns not only partial results but also an Admin Limit Exceeded error. While this is not the expected error, the intention of this setting is to cause client application logic to indicate that not all results are shown.

To set the criticality of a Join participant, use the dsconfig set-join-participant-prop subcommand. For example, the following command sets the criticality of a partition named joinparticipant-1 to true:

dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \ set-join-participant-prop --element-name we-join \
--participant-name joinparticipant-1 \
--set participant-criticality:true

14.12 Managing Operations that are Enabled

You can configure operations to perform on a Join participant using ds-cfg-enabled-operation parameter. A participant participates only in those LDAP operations specified in this parameter.

By default, a participant participates in search, compare, delete, and modify operations. You have to configure bind as enabled in that participant for it to participate in the bind operation. If you configure bind operation as enabled, then the configured bind priority determines the priority of the participant in processing the bind. The allowed values for this parameter are as follows:

  • SEARCH

  • ADD

  • MODIFY

  • DELETE

  • MODIFYDN

  • BIND

  • COMPARE

14.13 Handling Cascading Write Operations to Secondary Participants

You can cascasde write Operations, such as DELETE and MODIFY to secondary participants. This implies, when an entry is deleted from a primary participant, then the related entries in all secondary participants are also deleted. However, this is applicable only when DELETE operation is configured as an enabled operation in the associated secondary participant and the relationship between the original participant and the to-be-cascaded-delete participant is not many-to-one.

MODIFY operations are also cascaded to all eligible secondary participants based on their enabled-operations configuration and storable attribute configuration. ADD and MODIFYDN are cascaded only to shadow secondary participants based on the storable attributes configured in those participants.

14.14 Implementing Pass-Through Authentication Using Join Workflow Element

You can configure the Join workflow element to delegate bind requests to Authentication (Auth) Provider workflow element and non-bind requests to User Provider workflow element as depicted in Figure 14-6. This configuration also takes care of delegating MODIFY PASSWORD requests to Auth Provider workflow element and other MODIFY operations to User Provider workflow element.

Figure 14-6 Pass-through Authentication Using Join Workflow Element

Description of Figure 14-6 follows
Description of ''Figure 14-6 Pass-through Authentication Using Join Workflow Element''

Note that for simple pass-through authentication scenario, you should instead use the pass-through authentication workflow element that is described in Section 12.7, "Understanding Pass-Through Authentication." You must configure pass-through authentication with a Join workflow element only if you have special requirements that cannot be met with the pass-through authentication workflow element. For instance, the pass-through authentication workflow element does not route the bind requests to the User Provider workflow element, and the user password is stored only in the Authentication Provider workflow element. If you want a different deployment scenario, where you want to store the user password both in the Authentication Provider workflow element and in the User Provider workflow element, then you can use the Join workflow element and configure both providers to handle bind requests.

14.15 Handling LDAP Operations in Join Workflow Elements

If an attribute exists on both the primary and secondary participants, the attribute values are merged by the Join workflow element. For read operations, this implies that a multi-valued attribute is returned, with the values from all participants. For write operations, the proxy queries all participants and determines where to write the value based on the storable attributes configured in each Join participant.

Note:

You must keep the following in mind:

  • The Join workflow element displays a single value only, if there are multiple attributes with the same name from multiple data sources, for example two uid attributes from two different proxy workflow elements. However, you can configure the Join workflow element to retrieve attribute values only from a specific participant. To view the attribute from a specific participant only, you must ensure that the attribute is not listed in the Retrievable Attributes field for the participant for which you do not want to show the attribute for.

  • You must configure virtual ACIs correctly to grant or deny entries and attributes from a Join workflow element.

  • When a proxy workflow element is used as a Join participant, the credentials used to perform operations in each of the participant plays a significant role.

    - If the bind mode configured in proxy workflow element is use-specific-identity, then only specific ID is used for all non-bind operations.

    - If the bind mode configured in proxy workflow element is use-client identity, then actual client credentials are used if userDN is a descendant of any of the DNs configured in the include-list of a proxy workflow element. Otherwise, specific identity is used to perform operations in the proxy workflow element.

    - All proxy workflow elements must set the include-list to the respective user container DNs, so that bind correctly happens either with client DN or with specific identity. This also enforces that the user container of each participant must be unique. Otherwise, the bind fails.

    - Configure proxy and root credentials in proxy workflow element always, because some internal operations use this credentials. It is also required when you configure a include-list in a proxy workflow element.

The processing carried out by the Join Workflow element for various LDAP operations is described as follows:

14.15.1 ADD

  • Processed for primary participant based on storable attributes and enabled operation.

  • Processed only for shadow secondary participant based on storable attributes configured in it.

  • No processing done for secondaries in case of other joiners, except shadow joiner.

14.15.2 DELETE

  • Processed for all participants where DELETE is enabled.

  • Not processed for participants, which are on 1 side of Many-to-One relationship.

14.15.3 MODIFY

  • Processed in primary participant based on storable attributes and enabled operations.

  • For secondaries (any joiner type), modification is performed if the attributes in modification item is a storable attribute.

  • For shadow joiner:

    • Modify the shadow entry if the modify attribute needs to be stored in the shadow participant.

    • If the shadow entry is missing, create a new entry to store the modify attribute if it needs to be stored in the shadow participant.

    Note:

    For all secondary participants of different joiner types, all the attributes used in Join rule of that participant are implicitly treated as non-storable to maintain the link. So, modification of link attribute is not allowed through the Join workflow element. The operation would succeed, but the link attribute is not modified.In all participants where modify attribute is not a link attribute, modify takes place if that attribute is defined as storable.

14.15.4 MODDN

  • Processed in primary participant based on enabled operations.

  • For shadow joiner, the Join workflow element updates the shadow entry DN.

  • No processing done for secondaries in case of other joiner types.

  • For all joiners, MODDN is not allowed, if it is for link attributes and deleteoldrdn is set as true.

14.15.5 COMPARE

  • Processed in primary participant based on retrievable attributes and enabled operations.

  • If compare failed in primary participant, then COMPARE is processed in all secondaries based on retrievable attributes and enabled operations.

14.15.6 BIND

  • Processed in each bind participant based on bind priority.

14.15.7 SEARCH

  • Processed in primary participant first. Then, for each entry returned from Primary participant, which satisfies the join condition, the entry is joined with all eligible secondary participants.

Note:

The Join workflow element displays a single value only, if there are multiple attributes with the same name from multiple data sources, for example two uid attributes from two different proxy workflow elements. However, you can configure the Join workflow element to retrieve attribute values only from a specific participant. To view the attribute from a specific participant only, you must ensure that the attribute is not listed in the Retrievable Attributes field for the participant for which you do not want to show the attribute for.

14.16 Creating and Configuring Join Workflow Elements Using dsconfig Command

This section explains how to create and configure Join workflow elements and includes the following sections:

14.16.1 Prerequisites for Creating a Join Workflow Element

It is recommended that you first create the workflow elements associated with the respective participants, before you create the Join workflow element. This simplifies the Join workflow element configuration.

14.16.2 Configuring a Join Workflow Element Topology

This section describes how to configure a Join workflow element topology.

The steps listed in this section to configure a Join workflow element are based on the assumption that you meet the criteria mentioned in Section 14.16.1, "Prerequisites for Creating a Join Workflow Element," which is to create the necessary workflow elements required by the respective Join participants.

Consider the scenario, where you have two separate Proxy workflow elements. The first Proxy workflow element, we-proxy1 will be linked to the primary participant of the Join workflow element configuration. The second Proxy workflow element, we-proxy2 will be linked to the secondary participant of the Join workflow element configuration. For more information about creating Proxy workflow elements, see Section 18.1.1.3.3, "To Create a Proxy LDAP Workflow Element."

Assume, there is an entry in we-proxy1 data source as follows:

dn:cn=john,cn=users,dc=com1
objectclass:inetorgperson
cn:john
sn:doe
uid:jdoe
title:PMTS
description: This entry is from we-proxy1

Assume the following entry is present in we-proxy2 datasource:

dn: sn=doe,cn=employees,dc=com2
empid: jdoe
cn:John
sn:doe
department: Sales
manager: userid=smith,cn=users,dc=com2
description: This entry is from we-proxy2
objectclass:inetorgperson

Now the joined-entry returned from Join Workflow element would be:

dn:cn=john,cn=users,dc=join
objectclass:inetorgperson
cn:john
sn:doe
uid:jdoe
empid: jdoe
title:PMTS
description: This entry is from we-proxy1
description: This entry is from we-proxy2
manager: userid=smith,cn=users,dc=join
department: Sales

For the scenario described in this section, perform the following steps to configure a Join workflow element topology:

  1. Create a Join workflow element, named we-join.

    dsconfig create-workflow-element --set enabled:true \
--set join-suffix:dc=join --type join --element-name we-join \

    You need to provide the following information to create a Join workflow element:

    >>>> Specify Oracle Unified Directory LDAP connection parameters
 
Directory server hostname or IP address [ip]:
 
Directory server administration port number [4444]:
 
Administrator user bind DN [cn=Directory Manager]:
 
Password for user 'cn=Directory Manager':
 
 
>>>> Configure the properties of the Join Workflow Element
 
        Property                Value(s)
        ---------------------------------------------------------------
    1)  dn-attribute            manager, member, memberof, uniquemember
    2)  enabled                 true
    3)  join-suffix             dc=join
    4)  populate-joinedentrydn  false
 
    ?)  help
    f)  finish - create the new Join Workflow Element
    q)  quit
 
Enter choice [f]: f
 
The Join Workflow Element was created successfully

  2. Create a primary participant, named jp-p1 that is linked to the Proxy workflow element named, we-proxy1.

    dsconfig create-join-participant --element-name we-join \
--set participant-dn:dc=com1 \
--set participating-workflow-element:we-proxy1 \
--set primary-participant:true --type generic --participant-name jp-p1 \

    You need to provide the following information to create a primary participant:

    >>>> Specify Oracle Unified Directory LDAP connection parameters
 
Directory server hostname or IP address [ip]:
 
Directory server administration port number [4444]:
 
Administrator user bind DN [cn=Directory Manager]:
 
Password for user 'cn=Directory Manager':
 
 
>>>> Configure the properties of the Join Participant
 
         Property                        Value(s)
         ----------------------------------------------------------------------
    1)   enabled-operation               compare, delete, modify, search
    2)   join-condition                  By default, no join condition is
                                         defined. That is all entries
                                         satisfying the original search filter
                                         are considered for join.
    3)   joiner-type                     one-to-one
    4)   non-retrievable-attribute       By default, the non-retrievable list
                                         is empty, which means that all
                                         attributes are retrievable.
    5)   non-storable-attribute          By default, the non-storable list is
                                         empty, which means that all attributes
                                         are storable.
    6)   participant-bind-priority       0
    7)   participant-criticality         true
    8)   participant-dn                  dc=com1
    9)   participants-join-rule          ""
    10)  participating-workflow-element  we-proxy1
    11)  primary-participant             true
    12)  retrievable-attribute           By default, the retrievable list is
                                         empty, which means that all attributes
                                         are retrievable.
    13)  storable-attribute              By default, the storable list is
                                         empty, which means that all attributes
                                         are storable.
 
    ?)   help
    f)   finish - create the new Join Participant
    q)   quit
 
Enter choice [f]: f

The Join Participant was created successfully.

  3. Create a secondary participant, named jp-p2 that is linked to the Proxy workflow element named, we-proxy2.

    dsconfig create-join-participant --element-name we-join \
--set participant-dn:dc=com2 \
--set participating-workflow-element:we-proxy2 \
--set primary-participant:false --type generic --participant-name jp-p2 \
--set participants-join-rule:jp-p1.uid=jp-p2.empid

    You need to provide the following information to create a secondary participant:

    >>>> Specify Oracle Unified Directory LDAP connection parameters
 
Directory server hostname or IP address [ip]:
 
Directory server administration port number [4444]:
 
Administrator user bind DN [cn=Directory Manager]:
 
Password for user 'cn=Directory Manager':
 
 
>>>> Configure the properties of the Join Participant
 
         Property                        Value(s)
         ----------------------------------------------------------------------
    1)   enabled-operation               compare, delete, modify, search
    2)   join-condition                  By default, no join condition is
                                         defined. That is all entries
                                         satisfying the original search filter
                                         are considered for join.
    3)   joiner-type                     one-to-one
    4)   non-retrievable-attribute       By default, the non-retrievable list
                                         is empty, which means that all
                                         attributes are retrievable.
    5)   non-storable-attribute          By default, the non-storable list is
                                         empty, which means that all attributes
                                         are storable.
    6)   participant-bind-priority       0
    7)   participant-criticality         true
    8)   participant-dn                  dc=com2
    9)   participants-join-rule          jp-p1.uid=jp-p2.empid
    10)  participating-workflow-element  we-proxy2
    11)  primary-participant             false
    12)  retrievable-attribute           By default, the retrievable list is
                                         empty, which means that all attributes
                                         are retrievable.
    13)  storable-attribute              By default, the storable list is
                                         empty, which means that all attributes
                                         are storable.
 
    ?)   help
    f)   finish - create the new Join Participant
    q)   quit
 
Enter choice [f]: f
 
The Join Participant was created successfully.