RE: back-ldap connection caching, proxy controls?

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Phil Mayers [mailto:p.mayers@ic.ac.uk]

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

X.500 DSP provides per-operation signing and encryption as well. This is
really where I'd like to see things go.

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

Not very new, but essential for fully distributed operation. At present
there is no intrinsic LDAP specification for supporting distributed
authentication, for example. This is a killer problem as directories get
used more and more, for real. You start with a single database for all your
users, then as growth occurs over time, you need to split your database to
allow yourself to scale upward. All of a sudden your nice, unified namespace
is broken into isolated pieces. You set up referrals so that you can still
search the entire namespace, but you can no longer BIND to the entire
namespace; half of your users are in one piece and the other half are in the
other piece. Binding via referral only authenticates you on the piece where
your entry lives, and you're just pariah on the other pieces where your
account doesn't live.

You can sort of work around this problem using SASL as a frontend to some
other distributed authentication system (like Kerberos thru SASL GSSAPI, or
X.509 using TLS and SASL EXTERNAL). In this case, your bind DN is
independent of the LDAP databases you are trying to access. But I consider
this a kludge, a bandaid put on top of a gaping hole in the specification.
Given the fact that LDAP itself is beginning to be used as the backing store
for these other authentication systems (and rightfully so!) the need for
distributed authentication within the LDAP spec is still a problem that
needs a solution.

This is one of the problems that the X.500 DSP spec solves; it provides a
secure way for meaningful proxying to be done. It provides a way for a
directory server to vouch for a user's identity to another directory server.
So when user A authenticates to server B and makes a request that needs the
services of server C, server B can forward the request on user A's behalf,
and server C, who doesn't hold any information about user A, can still honor
the request because server C trusts server B. Furthermore, server C can
meaningfully enforce access controls based on user A's name, rather than
just using anonymous privileges.

This capability is absolutely essential, as my database split scenario above
illustrates. I know I've ranted about this topic quite a lot before, and
some of you who've seen it in the past may be tired of hearing it, but the
problem is real and is not going away; it's only getting worse as the number
and size of LDAP deployments grows...

In order to keep the directory framework manageable as it grows you need the
capabilities that the X.500 DSP chaining arguments provide to X.500 - reuse
of a single connection between cooperating directory servers, to keep
network socket resource consumption down. Individually authenticated
requests, with optional signature verification, to allow distributed
authentication. Plus all the other bookkeeping stuff to allow loop-detection
when a request is forwarded multiple times, etc...

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