directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: [SASL] SASL plan
Date Tue, 06 Mar 2007 22:38:51 GMT
On 3/6/07, Alex Karasulu <> wrote:
> ...
> 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?

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.


View raw message