directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: [ApacheDS] Things to consider for big bang refactoring
Date Mon, 01 Oct 2007 18:28:29 GMT
On 10/1/07, Emmanuel Lecharny <> wrote:
> ...
> I suggest that we feed the Roadmap with any other issues. We can then
> trigger the roadmap to make it reasonable given the timeframe and
> workforce we have.

Biggest problem I can think of for possible short-term inclusion is
that 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, eg Quanah/Stanford,
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 and, looking
now, quite possibly this is the issue behind DIRSERVER-1068.  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.

Alex asked me back in July to come up with a proposal.  The best
solution, IMO, would be a component that used 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.  Of course, this is exactly what OpenLDAP does and I can't
think of anything better.  We could either re-use this proposed
component in LDAP, Kerberos, and Change Password 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.

If any of this makes sense, I could code up a prototype and commit to
my sandbox.  Also, I did at one point, start a draft doc in the cwiki


View raw message