Re: java api bind() methods

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

At 10:53 AM 4/4/01 -0700, Rob Weltman wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> At 08:44 AM 4/4/01 -0700, Rob Weltman wrote:
>> >"Kurt D. Zeilenga" wrote:
>> >> Also,
>> >> >   Parameters are:
>> >> >
>> >> >      dn              If non-null and non-empty, specifies that the
>> >> >                      connection and all operations through it should
>> >> >                      be authenticated with dn as the distinguished
>> >> >                      name.
>> >>
>> >> This implies the provided DN is the authentication identity to
>> >> be associated with the connection.  Generally, the authentication
>> >> identity to be associated with the connection is that provided in
>> >> the credentials associated with the SASL mechanism.
>> >
>> >  If the provided DN is non-null and non-empty, then it is the credential that will be provided to the SASL mechanism(s).
>> 
>> IMO, that's inappropriate for a number of reasons.  First, it
>> disallows the client from specifying a different bind name
>> from a SASL authentication identity (which may be useful in
>> some environments).  Second, it assumes that the mechanism
>> used supports an identity in the form of an LDAP DN.  I note
>> also that mechanisms such as DIGEST-MD5 are designed to work
>> with arbitrary UTF-8 user names and as such two strings which
>> might represent equivalent LDAP DNs are not generally treated
>> as equivalent user names.
>> 
>> >If the SASL negotiation is successful, it will be the authentication identity.
>> >
>> >  If the provided DN is null or is empty, the SASL mechanism will (unless it is the external or the anonymous mechanism) use a callback to obtain a credential from the application if a callback is available.
>> 
>> The SASL callback should be used regardless of whether the provided
>> DN is null or empty.  The provided bind DN should ONLY be used as the
>> bind name.
>
>  That is all up to the mechanism implementation.  Neither the Java LDAP API implementation nor an application can force a mechanism (which is protocol-independent and most likely from a different supplier than either the LDAP API implementation or the application) to call back to an application.
>If it decides to call back, it will. If it decides to use the bind DN as sole credential identity, it will do so.

Only because the API told it that the bind name was the SASL
authentication identity.  The bind name is NOT the SASL
authentication identity.  It's whatever the user provides
(upon callback or other means) as the SASL authentication
identity.

>If it decides it needs additional credentials, it will request them through a callback. The Java LDAP API neither can nor should define or restrict how a SASL mechanism uses credentials during authentication.

The Java LDAP API should not be providing the bind name as a
SASL authentication identity.  It should leave the specification
of the SASL authentication identity to the application through
interaction with SASL API.  The LDAP API is just fouling the
works by assuming that bind name is or could be the SASL
authentication identity. 

Assuming use of SASL/DIGEST-MD5, how would an application
specify the use of a bind name which is different from
the DIGEST-MD5 authentication identity in a reliable manner?