RE: back-ldap connection caching, proxy controls?

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

Just thinking out loud about what mechanisms would be useful...

In the context of split databases and referrals, it would be nice if the
referring server sent back usable credentials along with the referral. I.e.,
some form of the currently bound user's credentials that can be validly used
on the target server. These credentials would then be used on any rebinds
that occur in chasing the referrals.

For a distributed Bind you need the same kind of token to be returned to the
client, containing the credentials from the Bind. (This all sounds like
Kerberos tickets to me, now that I think of it.)

In the context of proxying and chaining, you send this credential token with
the individual requests that are forwarded.

It's actually a lot easier to support secure proxying and chaining, because
in the presence of a trusted server-to-server session all you need to pass
is the user's username along with the requests. When you have to pass back a
security token to the client so that it can chase referrals, the token
becomes a very sensitive piece of data, it needs to have an expiration time,
be signed by the authenticating server, etc... It can get quite messy, and
involves extra overhead for each receiving server to validate the token.

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

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Howard Chu
> Sent: Thursday, May 02, 2002 3:24 PM
> To: Phil Mayers
> Cc: openldap-devel@OpenLDAP.org
> Subject: RE: back-ldap connection caching, proxy controls?
>
>
> > -----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