Enrique Rodriguez a écrit :
I have SASL working; that is to say, the DIGEST-MD5, CRAM-MD5, and
GSSAPI mechanisms.
Great ! This is one excellent news !
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.
I think the best solution would be to look at server-unit tests, where
an embedded ADS is launched, so you don't have to launch the server before.
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.
What about pushing the code in a branch so that we can help without
breaking the serve r(we are currently in the process to close a 1.5.0
version) ? Not that we really care to break the server, but we want to
tag this one, before adding new features. Let say that SASL can be
introduced in 1.5.1 (FYI, 1.5.0 is expected in the next two weeks, and
it's pretty much about fixing some bugs)
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.
It would be very appreciated if you can add a 'big-picture' somwhere in
confluence. The new site is now directly linked to confluence, and in
the 1.5.0 page, you can add this page somewhere in
http://directory.apache.org/apacheds/1.5/apacheds-v15-advanced-users-guide.html
(the little light grey icone on the upper right side of the main frame
is used to edit the page)
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
yet.
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.
hmmm... My bet is that it would be better to configure such things using
ADS itself. We are now trying to figure out a way to store all the
configuration into the server as Ldap entries, instead of having a giant
server.xml file. This is a work in progress, but certainly a way to go.
I could use some guidance on how to proceed. Mostly I'm wondering if
it's worth branching or not.
IMHO, yes. As your great work is pretty much parrallel (except for
BindHandler), branching won't harm.
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.
Enrique
Thanks Enrique, we were expecting this SASL for a very long time, this
is such a feature which make ADS a better server !
Emmanuel
