This is great.

On 3/5/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
I have SASL working; that is to say, the DIGEST-MD5, CRAM-MD5, and

So basically this handles the client side generation of the digest which is
sent to the server rather than the password itself, then the server compares
this digest with the digest generated from the userPassword field?

Stefan Zoerner last year hooked up a way to use digested passwords in the
userPassword field I think.  I wonder if there could be issues with SASL and
this mechanism if the password value in the entry is already really a digest
rather than the password itself in plain text.  Just wanted to mention a potential
problem here.  I guess you can just check if {SHA1} {MD5} prefixes are present
in the password value before performing the test.  If it is then if the digest algol
matches then just compare the supplied value with the digest values stored.

If not you can just throw an exception since you cannot generate a digest because
the userPassword is not in available to do so.

I may be totally off here since I'm twice removed from this code and I may
have some misconceptions about how these mechanisms actually work but
I just thought I'd mention it here for the record.

GSSAPI mechanisms.  The integration tests just completed (27 minutes
on a POS box).  

FYI if you have enough RAM you can setup a kernel parameter for setting up
larger ram drives limit is 768MB btw.  Then you can just combine them using
mdadm with RAID 1.  I can cut down the test run time by more than half when
doing this.

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.

You can actually extend AbstractServerTestCase or something like that in server-unit.
This puppy starts up the server with all the networking and services (even searches for
an available port and stores that in a protected member for your test methods to query).
Just extend this, and lookup the port the server is running on and use that to test the
SASL capabilities.  This way your integration tests will work on all machines regardless
of port availability.
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.

Understood sometimes that just happens.  Perhaps as Emmanuel recommended in another
response, you can just create a branch and work in there.  Then we can merge the features
back into the main line.  Just stay disciplined and don't do too many things that do not relate
to the task at hand so the diffs can easily be reviewed without clutter (for example don't reformat
code which masks the key changes for new features)

The BindHandler is totally replaced.  

Yeah I expected that.  It just selects a different work flow based on the sasl flag of
the bind request I guess.

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.

Aye you mean a MINA filter I guess.  Yeah that makes sense.

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

Sure this is really easy to do with the Spring stuff although a little tedious.
I can help with these tasks.

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

No problem ... small steps till we get to what the users like.  Might be a good idea
to just get it tight and working and release the feature.  Then solicit some feedback
from the users to see what they want to see put into the next round?  Just an idea.

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.

That rocks!

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.

Yep I can take care of that. I was meaning to setup a properties file at some point
that can be used to merge values into the rootDSE without code changes.  I might
do this or just add these values for you.  Just create a sub task for what you want
done and assign them to me.  I can get to them fast.

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.

Branching is a good idea I think.  I would do the same myself for big changes that touch
multiple peices of code.