directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] Things to consider for big bang refactoring
Date Tue, 02 Oct 2007 06:21:10 GMT
Enrique,

I'm not ignoring you and have some ideas to share on this topic as I
confronted the same
issue with the delegated authentication mechanism for LDAP.  I'd like to
talk about this
on this or another thread but I'm presently preoccupied with work, bigbang
branch and other
things.  I'll try to get back to you on this right after the JNDI cleanup.

Alex

On 10/1/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
>
> On 10/1/07, Emmanuel Lecharny <elecharny@gmail.com> 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
> sandbox.
>
> Enrique
>

Mime
View raw message