Re: back-ldap connection caching, proxy controls?

[Phil Mayers <p.mayers@ic.ac.uk>]

On Fri, 2002-04-19 at 14:36, Howard Chu wrote:
> 
> To get the benefit of such a setup, back-ldap needs to be configurable with
> an option to keep an outbound connection instead of unbinding it when the
> inbound connection unbinds. As I see it, this is perfectly safe as long as
> the only operations being performed are binds, you can just keep binding
> over and over again on the same connection. The old pam_ldap did this, also
> the Apache auth_ldap.

Simple binds, presumably? You'd have to be careful with SASL binds which
negotiate an encryption key - does the second bind use the second or
first negotiated SSF? But for simple binds, it'll work.

> 
> If you throw searches into the mix to support pam_ldap and nss_ldap it gets
> a little more questionable. Since pam_ldap (from PADL) does more than just
> authentication, the benefit gets even hazier.
> 
> What would help make this proxying really useful would be a Control that can
> be sent along with an operation, specifying an authzID for that operation.
> Also a Control for the Bind request, allowing it to accumulate IDs instead
> of resetting the current connection. The idea being, you can only specify an
> authzID that you have already bound as, on subsequent tagged operations.

This is similar to the way SMB works (SessionSetupAndX generate a
session ID that it prefixed to each subsequent SMB - this allows e.g. a
Win2K terminal server to multiplex serveral users down the same pipe.
The encryption there is per-pdu and happens after the "uid" portion of
the PDU, so they don't have the same problems with simple versus SASL
binds).

> 
> Some default needs to be established for subsequent operations that arrive
> without any authzID tag. One way would be simply to require that the first
> Bind on a connection be a "normal" one, and this is the ID used by default
> on untagged operations. Another approach would be to allow tagging a
> particular Bind request as the default ID... I suppose I should go re-read
> the X.500 DSP spec before going too far down this path.
> 
> Any thoughts?

An intruiging idea...

> 
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support
-- 

Regards,
Phil

+------------------------------------------+
| Phil Mayers                              |
| Network & Infrastructure Group           |
| Information & Communication Technologies |
| Imperial College                         |
+------------------------------------------+