[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: proxyAuthz propagation in back-ldap



> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga

Sorry for joining in late...

> Guess I not sure what you're trying to do with proxyAuthz.
> Here are my thoughts on reasonable usage (ignoring your
> message).
>
> When back-ldap is being used establish the clients identity,
> that is, it is chaining (simple) bind requests to a remote
> server (say in an environment where some of the user entries
> are on a remote server), then back-ldap should not use
> proxy authz control (and no binddn set).

This is how things worked before. It means that while most clients'
operations can be carried out over a shared remote session, a separate
connection to the remote server is needed to handle Bind requests. Without
mutex locking in back-ldap for the Bind, it means a separate connection is
needed per Bind request. Either way it tends to defeat the efficiency gains
from sharing remote sessions.

> When back-ldap is being used to chain client access requests
> (search, modify, etc.), then a number of different options
> should be available.

> 1) Proxy Anonymous, Forward Anonymous
>         no binddn, no proxy control

You mean, the client bound anonymously to the proxy server, so all its
requests will be forwarded anonymously to the remote server? OK. This is also
how things worked before; all anonymous requests share a session. (And
back-ldap never sees the anonymous Bind request.)

> 2) Proxy Authenticated, no forward
>         binddn, no proxy control

Meaning, the client is authenticated, but it is not searching for anything
that leads to the remote server? OK.

> 3) Proxy Authenticated, Forward Anonymous
>         binddn, anonymous proxy control

Without the ProxyAuth control support (I haven't looked closely at what it
does) this is partially the case. If the client authentication was a Simple
Bind that back-ldap forwarded to a remote server, then all operations with
that remote server are authenticated. If the authentication was handled by
something else, then the operations are forwarded anonymously. I believe the
point of adding ProxyAuth support to back-ldap is to be able to turn this
situation into case 4:

> 4) Proxy Authenticated, Forward client's identity
>         binddn, proxy control with client's id

The point being, no matter what mechanism was used to validate the client's
identity, this identity is propagated to all remote servers.

> (The proxy anonymous, client authenticated case is
> nonsense.)

In a *chaining* situation that's true. In a *proxy* situation this is a very
common use.

We need to be conscious of the fact that chaining and proxying are driven by
two very different purposes, even though there may be overlap in how they are
done.

Chaining is really about coordinated distributed operation - a single DIT is
fragmented and distributed across a body of servers, all of whom are
explicitly set up to trust each other and cooperatively serve the original
DIT - it's inherent in X.500, it's alien to the LDAP worldview.

Proxying is about tunneling from one namespace to a foreign namespace. There
is no trust or association of any kind between the communicating servers or
their DITs. This is the only thing that LDAP has been capable of thus far,
because LDAP provided no mechanism for distributing trust.

My original purpose for back-ldap was to take a stab at chaining, but it fell
short of the mark and proxying was the best it could achieve. Today things
may be a bit different.

> (note: if the client itself provides a proxy control,
> the proxy should reject the operation (e.g., not chain it)
> (possibly returning 'referral').  Also, each proxy generate
> proxy control should be marked critical.)

I'm not sure why this is required. The draft spec does not prohibit multiple
instances of this control from appearing in a request. Currently if slapd
receives multiple instances, they will be processed in order. As such, if the
client-supplied proxy control is handled after the back-ldap inserted proxy
control, the result will be as desired.

> I think you are suggesting a 5th usage:
>
> 5) Proxy Authenticated, Forward specific identity
>
> Personally, I don't see much value in this, at least not
> when forwarding the specific identity on a per operation
> basis.  It would be better for the proxy to provide
> that during authentication (as a authzid).

Hm... Perhaps I misinterpreted the previous couple points.

The goal is definitely to allow back-ldap to authenticate as itself (whatever
reserved identity that might be) and forward requests from multiple clients
(with their identities) over a single session to a remote server.

> 2a) Proxy Authenticated (w/ authzid), Forward Anonymous
> 3a) Proxy Authenticated (w/ authzid), Forward client's identity

> Of course, simple bind doesn't support authzid.  We could
> use a proxyAuthzid control to do that.

> 2b) Proxy Authenticated (w/ authzid by proxyAuth control),
> Forward Anonymous
> 3b) Proxy Authenticated (w/ authzid by proxyAuth control),
> Forward client's identity

This would require some rework, as right now the proxyAuthzid control would
get processed before the Bind is evaluated.

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