Draft - CatalogService Interceptor

Problem Statement

In a number of places, we limit principal lookup to a single "search base DN." We have the single vs. multi-base search mechanism for Kerberos and Change Password, and this could work for SASL GSSAPI, but it definitely doesn't handle the other SASL mechanisms (they don't use Kerberos principals). Also, the Kerberos and Change Password single vs. multi-base search mechanism is insufficiently flexible. Other directory servers, like AD and OpenLDAP, allow principals to occur in any container, even if they are in the same realm. OpenLDAP uses regex's to allow this. In the real world, you want to segregate principals that are in the same realm but that are different principal types (such as users vs. services). You can do this with regex's that segregate principals with "host/" in their names vs. users, just as a simple example.

This issue comes up periodically as a 2nd-order problem, ie multi-realm support for Kerberos, CP, and SASL GSSAPI, as well as multi-zone support for DNS. A good, cross-ApacheDS solution would fix a number of usability issues and clean-up the legacy mess of single vs. multi-base search. As an interceptor, it could be seriously elegant and powerful.

Proposed Solution

The proposed solution is a component that uses regex's to map between an entity, like a Kerberos principal or SASL realm/user, and a DN, either the DN of the desired entity or a base DN for a subsequent search. We could either re-use this proposed component in LDAP, Kerberos, Change Password, and DNS or we could install it as an interceptor.

As an interceptor, we could have a system container, perhaps "ou=catalog,ou=system," under which there were regex's. Our internal JNDI clients could execute lookups for "(krb5PrincipalName=hnelson@EXAMPLE.COM)" against "virtual base DN" "ou=kerberos,ou=catalog,ou=system." That node would be populated with regex's from config XML (or LDIF) that would be processed and result either in (a) the "real base DN" to perform the search at or (b) as an interceptor, simply redirect the query in the interceptor service chain to the "real base DN." This is possible because the OperationContext's passing through the interceptor service chain are mutable and this would optimize the redirect since the query wouldn't need to be executed twice. In other words, to a JNDI client, a query against one search base results in an answer in a totally different search base.

Catalog Entries

A catalog entry is a mapping between an administrative boundary, such as a Kerberos realm or a DNS zone, and a search base DN used to lookup entries, such as Kerberos principals or DNS resource records. Put another way, a catalog entry is a mapping between a protocol-dependent namespace format and the location in the DIT to search for matching distinguished names (DN). Furthermore, there is the requirement that all of a realm's entries might not be under the same search base DN.

For example,

• you may wish to segregate user principals from service principals, but all entries are still in the same Kerberos realm.
• you may wish to segregate user principals from admin principals or even group principals by business unit "organizational unit" (OU).

For this level of flexibility, the CatalogService must support regular expressions (regex).

uid=(.*),cn=example.com
ldap:///uid=$1,cn=users,dc=example,dc=com??sub?krb5PrincipalName=service/$1@example.com

uid=service/(.*),cn=example.com
ldap:///cn=Service,cn=Applications,dc=example,dc=com??sub?krb5PrincipalName=service/$1@example.com

uid=webauth/(.*),cn=example.com
ldap:///cn=Webauth,cn=Applications,d c=example,dc=com??sub?krb5PrincipalName=webauth/$1@example.com

Affected protocols

Code

A proof-of-concept has been available since r581763. The TestCase's give an idea of typical regex's used for Kerberos principal to LDAP URL mappings.

http://svn.apache.org/viewvc/directory/sandbox/erodriguez/core-catalog/

However, the proof-of-concept does not yet store the catalog entries in the DIT - they are hardcoded in a HashMap structure.

Schema Discussion (TBD)

Schema Examples (TBD)