directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject [SASL] SASL plan
Date Tue, 06 Mar 2007 03:35:19 GMT
I have SASL working; that is to say, the DIGEST-MD5, CRAM-MD5, and
GSSAPI mechanisms.  The integration tests just completed (27 minutes
on a POS box).  New SASL integration tests are also complete.  I used
the JDK's JNDI client to test a variety of positive and negative
scenarios.  Also, I tested manually with the ldap-clients CLI tools,
eg ldapsearch.

I need to wrap up a few loose ends:
1)  My integration tests require a running server.  I just haven't
gotten around to figuring out how it's done elsewhere in ApacheDS.
I'll get on that next.
2)  I need to add javadocs.
3)  I triplicated a lot of code to make each mechanism work, so
there's one big round of refactoring due to tighten things up.

The BindHandler is totally replaced.  The execution path for the
Simple mechanism is unchanged and integration tests pass so I don't
think this is a major change.  Outside of the LDAP PP, a SaslFilter
needs to get added to the filter chains in ServerContextFactory.  The
'server-sasl' module can be deleted.

Most config is hardcoded, but I put it all in one class.  From there,
we can work it into the server.xml.

Also, none of the advanced regex's we talked about is done.  The deal
with authentication is that:
CRAM-MD5:  looks for 'uid' under a base DN.
DIGEST-MD5:  looks for 'uid' under a base DN.  Realm must match realms
advertised by the LDAP server, but there is no multi-realm support
GSSAPI:  looks for a krb5PrincipalName under a base DN.  Also no
multi-realm support yet.

The ease of configuring GSSAPI/Kerberos really stands out.  Principal
configuration (user, service, krbtgt) can all occur on LDIF load,
which is really cool.  The implication, besides not relying,
server-side, on external config files, is that you also don't need to
export a service principal key from the directory, like you do with
standalone LDAP servers.

One last thing, the JDK's JNDI client checks the RootDSE for
'supportedSASLMechanisms', so we need to add that as the intersection
of configured mechanisms from the server.xml and the supported
mechanisms and return that from the DefaultPartitionNexus.

I could use some guidance on how to proceed.  Mostly I'm wondering if
it's worth branching or not.  Only the BindHandler in the
protocol-ldap module is affected, but we haven't started in on any
regex processing or moving authentication to actual Authenticators.


View raw message