You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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:

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
  • No labels