Re: java api bind() methods

[Rob Weltman <robw@coscend.com>]

"Kurt D. Zeilenga" wrote:
> 
> A few questions regarding the LDAPConnectionbind methods...
> 
> How does bind() interact with outstanding operations which
> are implicitly abandoned by the bind request?  In particular,
> with listeners for outstanding operations?

  As per RFC 2251 (to "simplify server implementation"), outstanding operations on the connection are abandoned. LDAPListener.getMessageIDs() returns a null-length array and LDAPListener.getResponse() throws an LDAPException.

 
> How does bind() behave when a referral is returned?  In
> particular, if the referral is successfully chased, what
> is the authentication state of the connection?

  If the API implementation successfully chases the referral and the bind completes successfully, the state of the connection is authenticated. This may or may not make sense in a particular environment. In some cases it may be a sign of an incorrectly configured server. In others there may be a pass-through authentication mechanism in place (such as that of the iPlanet Directory Server).

 
> How does an application cancel an in-progress SASL multiple-step
> bind operation?  Maybe an empty (not null) mechanism could be
> used for this.

  That is what is suggested by RFC 2251 (issue a new SASL bind request with an empty mechanism name).

 
> During an in-progress SASL multiple-step bind operation, what
> happens with one attempt to issue other operations upon the
> same session (via a clone of the connection)?

  Nothing. When a clone begins a bind operation, it is dissociated from its siblings.


> The SASL bind() methods appears to negotiate mechanisms between
> those requested by the application and those advertised by the
> server.  If so, is there a way to disable this negotiation and
> explicitly mandate the use of a particular mechanism?

  See below.

 
> I am also concerned by this statement:
>    If mechanisms is null, or if the first version of the method
>    is called, the LDAP server will be interrogated for its
>    supportedSaslMechanisms attribute of its root DSE.
> 
> This implies supportedSaslMechanisms is not checked after:
>         1) reconnection
>         2) StartTLS()
>         3) establishment of SASL provided security services

  Short summary of SASL mechanism negotiation: successful completion of SASL authentication requires that the client and the server support at least one mechanism in common. If the server supports mechanisms a - d and the client supports mechanisms c - f, they can negotiate authentication using mechanisms c or d.

  The way a client or server indicates which mechanisms it supports is different for different protocols. LDAP is somewhat unique in that the server publishes a list of supported mechanisms outside of any authentication process. With IMAP, for example, the client just proposes a mechanism and the server either accepts it or rejects it, forcing the client to try various mechanisms until it finds one that the server accepts. [ftp://ftp.isi.edu/in-notes/rfc2222.txt].

  The first version of my I-D on a Java SASL binding followed the low-level RFC 2222 sequencing closely. An application would have to try each mechanism it was capable of until it found one that the server accepted. But after discussions with John Myers (author of SASL) and with a couple of the implementors of the Cygnus SASL project at CMU, I modified the I-D to put the responsibility on the middleware (i.e. the API) implementation and on the site administrators instead. As currently envisioned, a site administrator will typically configure the mechanism factories that she will allow applications to use at her site. That configuration may limit the number of mechanisms that are available to a server or client at the site and also establish a priority order among them. An application doesn't need to know anything about them. The Java SASL API implementation is responsible for attempting to use only the site-configured mechanisms and to attempt each one in the site-configured!
 order. An application can find out afterwards which mechanism was ultimately negotiated, but it cannot (at least not directly) find out which mechanisms were discussed during the negotiations. That is also the approach of the C SASL binding developed at the Cygnus project (at least as it was presented to me by a couple of its developers).

  The fact that in LDAP the supported mechanisms are published outside of an authentication session can and should be used by a Java LDAP API implementation to conserve bandwidth (i.e. not attempt to authenticate with a mechanism not supported by the server) but it doesn't affect the ultimate selection of mechanisms because that is defined by the site configuration of the client and that of the server. The proposed Java LDAP API still allows a client to limit the acceptable mechanisms to a subset of the site-configured ones.

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

Rob