directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [SASL] SASL plan
Date Tue, 06 Mar 2007 14:20:20 GMT
Enrique,

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
> yet.


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.

Thanks,
Alex


Enrique
>

Mime
View raw message