Subject: LDAPBind needs - java-api-11 draft

From: "Steve Sonntag" <[email-masked]>
Date: Thu, 07 Sep 2000 13:56:11 -0600

Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt

It is unclear from the draft how the LDAPConnection object must be
used by an application implementing the LDAPBind interface.

I am guessing that the LDAPConnection object passed to the bind()
method of the LDAPBind implementation is a new LDAPConnection object
created by automatic referall following code in the original LDAPConnection
object. The object contains the  AuthenticationDN and
AuthenticationPassword from the LDAPConnection that the continuation
reference was received on. The Host and Port are filled in from the
referral/reference host & port. When passed to the bind() method,
neither connect nor bind has been performed on this LDAPConnection object.

In order to make this work, I believe the iimplementation of the
LDAPBind.bind() method MUST use the LDAPConnection object, which
was passed as a parameter, to perform its connect and bind calls.
It then returns success if both operations succeed.  The original
LDAPConnection object referral handling code can then use the
new LDAPConnection object when it resends the search request,
updated with the new search base and possibly search filter.

The above should be clarified in the draft.

It seems that the LDAPRebind interface would be easier to implement if
additional data were provided in the new LDAPConnection object.  Such as:

1. A reference to the LDAPSocketFactory class from the original LDAPConnection
    object.  This allows it to connect in the same way as the original connection.
2. An LDAPConstraints object containing a reference to the LDAPRebind object
    from the original LDAPConnection object.  The LDAPBind.bind() method may
    want to get authentication information using and LDAPRebindAuth object, and
    this gives it a way to do that.
3. The protocol version used in the connect/bind of the original object.  This allows
    The LDAPBind.bind function to bind with same protocol version used in the
    original connection.
4. The mechanism used when binding.  This could be the mechanism used on the
    bind in the original LDAPConnection object, or perhaps LDAPRebindAuth could
    be modified to provide the triplet - UserDN, Password, and Mechanism for the
    specified host.

IMO the above changes would give the application, using explicit bind, greater flexibility 
when dealing with referrals / continuation references during automatic referral
following:

Comments?

Thanks,

Steve

---

From: [email-masked] (Rob Weltman)
Date: Thu, 07 Sep 2000 13:04:52 -0700

Steve,

  I haven't been able to respond immediately to the many messages of the past week with comments on the latest LDAP Java API draft, but I have been diligently collecting them and I plan to respond soon. My preliminary take is that there is enough substance to justify a new draft, and I'll submit one in a couple of weeks if that is the case.

  Thanks for all your (and Steven Merrill's) input!

Rob

Steve Sonntag wrote:

>  Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt It is unclear from the draft how the LDAPConnection object must beused by an application implementing the LDAPBind interface. I am guessing that the LDAPConnection object passed to the bind()method of the LDAPBind implementation is a new LDAPConnection objectcreated by automatic referall following code in the original LDAPConnectionobject. The object contains the  AuthenticationDN andAuthenticationPassword from the LDAPConnection that the continuationreference was received on. The Host and Port are filled in from thereferral/reference host & port. When passed to the bind() method,neither connect nor bind has been performed on this LDAPConnection object. In order to make this work, I believe the iimplementation of theLDAPBind.bind() method MUST use the LDAPConnection object, whichwas passed as a parameter, to perform its connect and bind calls.It then returns success if both operations succeed.  The origina!
lLDAPConnection object referral handling code can then use thenew LDAPConnection object when it resends the search request,updated with the new search base and possibly search filter. The above should be clarified in the draft. It seems that the LDAPRebind interface would be easier to implement ifadditional data were provided in the new LDAPConnection object.  Such as: 1. A reference to the LDAPSocketFactory class from the original LDAPConnection    object.  This allows it to connect in the same way as the original connection.2. An LDAPConstraints object containing a reference to the LDAPRebind object    from the original LDAPConnection object.  The LDAPBind.bind() method may    want to get authentication information using and LDAPRebindAuth object, and    this gives it a way to do that.3. The protocol version used in the connect/bind of the original object.  This allows    The LDAPBind.bind function to bind with same protocol version used in the    original connection.4. Th!
e mechanism used when binding.  This could be the mechanism used on th
indAuth could    be modified to provide the triplet - UserDN, Password, and Mechanism for the    specified host. IMO the above changes would give the application, using explicit bind, greater flexibilitywhen dealing with referrals / continuation references during automatic referralfollowing: Comments? Thanks, Steve

---

From: Steven Sonntag <[email-masked]>
Date: Thu, 07 Sep 2000 15:56:44 -0600

Steve Sonntag wrote:

>  Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt It
> is unclear from the draft how the LDAPConnection object must beused by
> an application implementing the LDAPBind interface. I am guessing that
> the LDAPConnection object passed to the bind()method of the LDAPBind
> implementation is a new LDAPConnection objectcreated by automatic
> referall following code in the original LDAPConnectionobject. The
> object contains the  AuthenticationDN andAuthenticationPassword from
> the LDAPConnection that the continuationreference was received on. The
> Host and Port are filled in from thereferral/reference host & port.
> When passed to the bind() method,neither connect nor bind has been
> performed on this LDAPConnection object. In order to make this work, I
> believe the iimplementation of theLDAPBind.bind() method MUST use the
> LDAPConnection object, whichwas passed as a parameter, to perform its
> connect and bind calls.It then returns success if both operations
> succeed.  The originalLDAPConnection object referral handling code can
> then use thenew LDAPConnection object when it resends the search
> request,updated with the new search base and possibly search filter.
>
> It is also necessary that the application implementing the
> LDAPBind.bind()
> method use a synchronous bind do bind to the referred-to-server, or
> if using an asyncronous bind, it must wait until the bind operation
> has
> completed before returnint status.
>
> -Steve
>
>
>
>
>
>
>   The above should be clarified in the draft. It seems that the
> LDAPRebind interface would be easier to implement ifadditional data
> were provided in the new LDAPConnection object.  Such as: 1. A
> reference to the LDAPSocketFactory class from the original
> LDAPConnection    object.  This allows it to connect in the same way
> as the original connection.2. An LDAPConstraints object containing a
> reference to the LDAPRebind object    from the original LDAPConnection
> object.  The LDAPBind.bind() method may    want to get authentication
> information using and LDAPRebindAuth object, and    this gives it a
> way to do that.3. The protocol version used in the connect/bind of the
> original object.  This allows    The LDAPBind.bind function to bind
> with same protocol version used in the    original connection.4. The
> mechanism used when binding.  This could be the mechanism used on
> the    bind in the original LDAPConnection object, or perhaps
> LDAPRebindAuth could    be modified to provide the triplet - UserDN,
> Password, and Mechanism for the    specified host. IMO the above
> changes would give the application, using explicit bind, greater
> flexibilitywhen dealing with referrals / continuation references
> during automatic referralfollowing: Comments? Thanks, Steve