Re: java api bind() methods

[Rob Weltman <robw@coscend.com>]

"Kurt D. Zeilenga" wrote:
> 
> At 08:44 AM 4/4/01 -0700, Rob Weltman wrote:
> >> 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.
> 
> That seems counter to section 4.6.6.  >>>emphasis added<<<
>    The clone can freely modify options and search constraints, and issue
>    requests, without affecting the source object or other clones. If the
>    clone disconnects or reconnects, it is completely dissociated from
>    the source object and other clones. >>>Reauthenticating in a clone,
>    however, is a global operation which will affect the source object
>    and all associated clones, because it applies to the single shared
>    physical connection. Any request by an associated object after one
>    has reauthenticated will carry the new identity.<<<

  True, as I wrote a little earlier today. Since clones continue to share the connection during and after binding, they are subject to the same requirements and behavior as a thread sharing the connection that is doing the bind:

   "Clients MUST NOT invoke operations
   between two Bind requests made as part of a multi-stage bind."

  Invoking an operation while bind is in progress will therefor result in an LDAPException being thrown, just as for a thread invoking an operation on the binding connection.

 
> >  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.
> 
> There are still cases, such as the existence of some
> a priori agreement or belief a man-in-the-middle has
> deleted a particular server supported mechanism, were
> the client wants to mandate a specific mechanism which
> is not listed by the server.  There is also the more
> common case where the client just wishes to avoid an
> unnecessary (to a particular application) discovery
> exchange.

  My comment was a response to your statement:

> 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


  How does reading the supported mechanisms of the server help in the cases you describe? If there is an a priori agreement on what mechanism(s) to use, or the client (I assume you mean the application) wants to mandate a specific mechanism, or to avoid a discovery exchange, why would the client even bother to read the supported mechanisms of the server?

Rob