Re: java api bind() methods

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:43 PM 4/4/01 -0700, Rob Weltman wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> >  Also, there are LDAP servers that only understand DNs and not usernames or other types of identity (as far as I know it does not conflict with RFC 2251 or other relevant documents for an LDAP server to only accept DNs for authentication, directly or through certificate mapping).
>> 
>> And the Application is free to provide a DN as the SASL authentication
>> identity.  But there are also LDAP implementations which don't understand
>> DNs as the authentication identity and make use of the bind name,
>> a DN, for other (non-authentication) purposes.  This is also not in
>> conflict with RFC 2251/RFC2829.
>> 
>> >A requirement that the bind DN not be the SASL authentication identity would not be reasonable for those servers.
>> 
>> That's not the requirement I'm after.  I'm after the requirement:
>>         The DN provided with a bind() call is sent to the server
>>         as the bind name.  It is not provided to the SASL layer
>>         as the authentication identity nor as the authorization
>>         identity.  The application may provide an authentication
>>         identity and/or authorization identity or other information
>>         appropriate used by the SASL mechanism to the SASL layer
>>         using the facilities of the SASL API.
>
>  The point is that you cannot require that, because you cannot mandate that a SASL mechanism will use the callback facility (which is all it has at its disposal) to ask the application for an authentication identity. It is up to the SASL mechanism. A DIGEST/MD5 mechanism will ignore the DN provided in the bind() call, send an empty credentials field to the server, and obtain credentials from the user with a callback. It will then use them to create a "digest-response" to send to the server. Other mechanisms will send the DN in the initial SASL bind request. They may or may not request additional credentials from the application. Again, it is up to the mechanism, not the Java LDAP API, to decide what credentials to use, how to use them, and when to obtain them.

My point is that it *should* be up to the application to specify
the value it wants to send as the bind name and the value it
wants to use as the authentication identity.  If the application
choose them to be the same or different, that's it's choice.
The job of the LDAP API is to provide a means for the application
to provide the value for specific uses, but not to make any
assumptions that a value provided in one use (a bind name) can
or should be used in another use (a SASL authentication identity).

If the application wants to do a DIGEST-MD5 authentication with
an bind name of "cn=john" and a SASL authentication identity of
"mary", the LDAP API should provide facilities to accomplish.
If this is not possible with the current LDAP API then the API
is flawed.

Kurt