Introduction

In this post, we look at a simple way to configure a chained LDAP authentication scheme in OAM 11g R2. This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

The problem we are trying to solve

Consider a situation where the users that need to be authenticated by Oracle Access Manager do not all reside within the same LDAP directory. This is a fairly common situation which can arise as a result of mergers and acquisitions, or even of IT consolidation between different departments or business units within a single organisation. While it may well be desirable to consolidate all user records into a single LDAP structure over time, often the immediate needs of the business are such that this simply wouldn’t be feasible in the short term, particularly if there are challenges in terms of data consistency, format, password storage and so on that would need to be overcome as part of a migration project.

While it is possible (and quite common) to address requirements of this nature using Oracle Virtual Directory – in short, inserting OVD in between OAM and the physical LDAP repositories in order to construct a single virtual tree – one can also use OAM’s pre-built authentication plugins to accomplish essentially the same thing, in a simpler way.

The solution described below has been built and tested against OAM 11g R2 PS2 (11.1.2.2). I cannot guarantee that it will work against older versions.

Creating a Chained LDAP Authentication Module

The first step here is to ensure that all directories containing user information are correctly configured as User Identity Stores within OAM. To demonstrate the concept, I installed two separate Oracle Unified Directory instances on my test server and added both as Identity Stores using the OAM console – the below screenshot shows OUDStore and OUDStore2, which refer to distinct directory instances as can be seen from the differing port numbers:

We then configure a custom Authentication Module, which will attempt to match the provided user ID against each of the directories in turn. In this simple example, the module will first do a lookup against the first directory (OUDStore). If that lookup succeeds, it will attempt authentication against OUDStore using the provided password. Should the intitial lookup fail, it will attempt the lookup against the second directory (OUDStore2). Again, should that lookup succeed, it will attempt authentication against OUDStore2 using the provided password. Should both lookups (or either password authentication step) fail, then the entire authentication attempt will fail.

We configure the module by including two instances of both the UserIdentificationPlugin and the UserAuthenticationPlugin. Both are standard OAM plugins that ship with the product.

The screenshots below demonstrate the configuration of our ChainedLDAP custom Authentication Module:

This next screenshot shows the orchestration flow through the various steps:

Note that “OUD1ID” (User Identification against OUD 1) is the first step. On failure of this step, we execute “OUD2ID” (User Identification against OUD 2). Note also that successful completion of either of the two User Authentication steps will result in a successful result for the orchestration as a whole.

The only remaining step is to build and Authentication Scheme that uses this new module. That can be done by cloning the standard “LDAPScheme” and changing the Authentication Module, as below:

When we assign the above Authentication Scheme to a resource within an Application Domain, we see that we can successfully authenticate using credentials from either of the OUD instances.

What about Authorization?

Extending the use case a little, we can build authorization conditions that make sense in this case by specifying group membership rules across both directories. In the screenshots below, as an illustration, I’ve included separate group membership conditions for each OUD instance, with an OR rule to ensure that either will allow access.

Some practical considerations and limitations

As with all approaches described on this site, this one is not a silver bullet. While it offers a simple way to allow OAM to authenticate users against more than one directory, it has a number of limitations, of which the below are just a few:

• Collision of user names is not handled well. In the case where the same user ID existed in both directories, only the first would be checked. It is, of course, not possible for a single login process to handle the case where ore than one distinct user has the same user ID in any case, but it is important to be aware of this limitations regardless.
• It is unlikely that this approach will scale particularly well beyond a handful of directories. You certainly wouldn’t want to check a user name against each of a large number of directories in sequence, for performance reasons.
• The complexities of defining meaningful authorization policies based on group memberships across multiple directories shouldn’t be underestimated. This approach is probably best used in situations where authorization requirements are not stringent (such as allowing all users within all directories to access resources)

All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission