[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: java api bind() methods

At 01:40 PM 4/4/01 -0700, Rob Weltman wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> 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?
>
>  It might help to show the layers of the SASL implementation:
>
>   -------------------------
>   | Application or server |
>   -------------------------
>   -------------------------
>   | Protocol driver       |
>   -------------------------
>   -------------------------
>   | SASL middleware       |
>   -------------------------
>   ------------------  ------------------  ------------------
>   | SASL mechanism |  | SASL mechanism |  | SASL mechanism |
>   ------------------  ------------------  ------------------
>
>  For a Java application using LDAP, the Java LDAP API implementation is the protocol driver. It shares the SASL middleware layer with other protocol drivers (e.g. imap). It would be wrong for a protocol driver to dictate a certain behavior to the middleware layer

YES!  By passing the LDAP bind name to the middleware layer, the
LDAP API dictating behavior which should be left to the application.
That is, the application should be the one dictating what the value
of the bind name is and what the SASL authentication identity
is.  The LDAP API should not assume that the application wants them
to be the same.

>, or to a mechanism. For example, it would be wrong to require that for LDAP "The SASL callback should be used regardless of whether the provided DN is null or empty.".

My point here is its the application which should drive what is
sent as the bind name and what is used as the SASL authentication
identity.  There are cases where they can and should be different.

>There are mechanisms that don't want credentials at all (ANONYMOUS and the anonymous of EXTERNAL) and mechanisms that only know how to deal with a single identity. The Java LDAP API can not and should not impose specific semantics

It is impose the semantics that the bind name cannot be different
from the user name by providing this value to the SASL middleware
layer.  The LDAP API should leave this to the application.

>(SASL/DIGEST-MD5 with a user name different from the bind DN) on the middleware layer or on the SASL mechanisms. The semantics of a specific mechanism are implemented by the mechanism.

>  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.