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

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.

Enrique

[ Post a follow-up to this message ]

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
[url]http://directory.apache.org/apacheds/1.5/apacheds-v15-advanced-users-guide.html[/u
rl]
(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

[ Post a follow-up to this message ]

Enrique,

This is great.

On 3/5/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:[vbco
l=seagreen]
>
> I have SASL working; that is to say, the DIGEST-MD5, CRAM-MD5, and[/vbcol]


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
>

[ Post a follow-up to this message ]

Alex Karasulu wrote:[vbcol=seagreen]
> 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 dige
st
> 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} prefix
es 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.[/vbcol
]

You are right, Alex. The feature is described (from a user's point o
view) here:

http://directory.apache.org/apached...on-options.html

But the server does not digest passwords on his own account, the user
(or his tools) has to calculate the value and transmit it. I still plan
to write a simple interceptor as an example for the docs, which exactly
does this, but this is another story.

Digesting userPassword values in conjunction with SASL DIGEST won't
work, we should clarify this in the documentation.

Greetings from Hamburg,
Stefan

[ Post a follow-up to this message ]

Hi Stefan,

Thanks for chimming in with the additional info.  It might come in handy for

what Enrique is working on.

Alex

On 3/6/07, Stefan Zoerner <stefan-EQq9qWhC7IA@public.gmane.org> wrote:
>
> Alex Karasulu wrote: 
> the 
> digest 
> stored.
>
> You are right, Alex. The feature is described (from a user's point o
> view) here:
>
> http://directory.apache.org/apached...on-options.html
>
> But the server does not digest passwords on his own account, the user
> (or his tools) has to calculate the value and transmit it. I still plan
> to write a simple interceptor as an example for the docs, which exactly
> does this, but this is another story.
>
> Digesting userPassword values in conjunction with SASL DIGEST won't
> work, we should clarify this in the documentation.
>
> Greetings from Hamburg,
>      Stefan
>
>

[ Post a follow-up to this message ]

On 3/6/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> ...
> So basically this handles the client side generation of the digest which i
s
> sent to the server rather than the password itself, then the server compar
es
> this digest with the digest generated from the userPassword field?

No, typically a password is combined with some information shared by
the client and server, to prove both sides know the same password,
avoiding the need for the password to traverse the network.  There are
2-3 request-response pairs here, negotiating session setup and
responding to challenges from the server.

> Stefan Zoerner last year hooked up a way to use digested passwords in the
> ...
> 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.

This is the case.  In other LDAP servers you have to explicitly
configure the server to store the password plaintext.

> You can actually extend AbstractServerTestCase or something like that in
> server-unit.

Cool, I'll migrate to that.

So, based on feedback from you and Emmanuel, I will:
1)  Branch the trunk to add SASL.
2)  Assign Alex a subtask to add supportedSASLMechanisms in the branch.
3)  Start a page in Confluence.

Enrique

[ Post a follow-up to this message ]

On 3/6/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:[vbco
l=seagreen]
> ...
> So, based on feedback from you and Emmanuel, I will:
> 1)  Branch the trunk to add SASL.
> 2)  Assign Alex a subtask to add supportedSASLMechanisms in the branch.[/vbcol]

An issue is open:
https://issues.apache.org/jira/browse/DIRSERVER-867

> 3)  Start a page in Confluence.

I started this page at:
http://cwiki.apache.org/confluence/...pacheD
S

Enrique

[ Post a follow-up to this message ]

Excellent! I'll watch for commits to figure out where your SASL branch is to
add the code to return the supportedSASLMechanisms in the RootDSE.

Alex

On 3/6/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:[vbco
l=seagreen]
>
> On 3/6/07, Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gman
e.org> wrote: 
>
> An issue is open:
> https://issues.apache.org/jira/browse/DIRSERVER-867
> 
>
> I started this page at:
>
> http://cwiki.apache.org/confluence/...pach
eDS
>
> Enrique
>[/vbcol]

[ Post a follow-up to this message ]