On 3/6/07, Alex Karasulu <[EMAIL PROTECTED]> 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.

Enrique

Reply via email to