Re: java api bind() methods

[Rob Weltman <robw@coscend.com>]

"Kurt D. Zeilenga" wrote:
> 
> 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.

  That is supported. It is also supported for a mechanism to not request a separate SASL identity but to either use the bind DN for that or to not use any identity (for ANONYMOUS or SASL). If you broaden the examination to mechanisms other than DIGEST-MD5 I think you will see that it is up to the mechanism, not the application, to decide what credentials are required and how and when to send them to the server.

Rob

> 
> Kurt