Introduction

Quite often LDAP directories are used to store application information about users and other principals without actually storing the credentials of these principals. Sometimes users and other principals do not have accounts within such directories but are referenced. Mapping these LDAP principals to their respective principals in external credential stores and forwarding the authentication to the external credential store is referred to as delegation of authentication (DoA).

The external credential store simply acts as a dumb access to a credential store or a validation engine where ApacheDS trusts this external mechanism.

Drivers

There are several common situations which drive the need for DoA. The most common corporate scenario is the use of Active Directory as the primary credential store for more enterprises. Active Directory serves as the database of record for the windows network operating system (windows domains). Often an "application directory" is needed for storing application specific information about principals but the credentials of users need not be replicated. In this particular situation there are specific inhibitors for storing application specific information in Active Directory:

1. The corporate directory backing windows domain account information is controlled by different authorities within the same organization. Often these authorities are not the same as those tasked with managing the application specific information in the application directory. Collaboration to effect changes requires too much coordination to be feasible for day to day management.
2. Application specific changes to the Active Directory schema cannot easily be altered or rolled out to accommodate new releases without disabling the rest of the windows domain infrastructure.
3. Unnecessary load for application specific information needs to be kept off domain controllers. This is a form of load partitioning.
4. Information in application directories can be better localized close to the applications that need to access them: with replicas.
5. Application directories can be embedded in applications as well whereas Active Directory cannot.

Requirements

There are several matters to consider when designing such a feature for the server. It's best that we define some requirements and discuss the various issues and concerns for users of such a feature before implementing it.

• DoA should be generalized to enable by extension the use of any external credential store or validation engine.
• DoA must be secure.
• DoA must enable principal mapping and delegation even when the principal authenticating at the forwarding DSA is not defined.
• DoA must be flexible enough to select any geometry of subtrees or refinements to map users to respective principals in external systems.
• DoA must be authentication level and authentication mechanism aware when evaluating whether or not to delegate authentication.
• DoA must be configurable enough to:
  • Allow multiple mappings with prioritization
  • Allow for multiple replicated credential stores to be balanced against.
• DoA should allow for marking credential stores as down and avoiding lengthy time outs when alternative replicas exist.
• DoA should Enable a proximity based waiting of external stores when evaluating delegation to minimize latency.
• DoA should allow selection of principals to delegate based on various characteristics:
  • attributes within the entries of existing principals
  • connection parameters of the principal being forwarded to the external store
• DoA should be an optional feature that can be activated by administrators.

Of course we cannot manifest all these requirements immediately. The implementation will evolve simply at first to eventually achieve these requirements. However these requirements should govern the progression of the feature over time. Furthermore the state and features of the server will progress to more readily enable meeting these requirements with time.

Initial Implementation

The initial implementation will try to accommodate these requirements with the time allocated but should be simple and easy for users to try and give feedback on. So the idea is to make it work and work well in the easiest way to use and maintain so more users use it and provide enough feedback for it's evolution to occur.

The most natural solution which will be the most common would be to enable delegation to external LDAP directories which act as authoritative credential stores for sets of principals. This can quickly be modeled as a custom Authenticator in ApacheDS however doing this may be somewhat limiting but time will tell.

The Authenticator will be configured with information for now within the server.xml file. The configuration will expose a means to configure a set of external LDAP replicas which can be used to load balance authentication requests with weighting information pertaining to preferred replicas in proximity. Grouping descriptors (a form of subtree specification) will also need to be specified to associate authenticating principal DN's with their respective principal DN's in external systems.

More to come ...