Re: proxyAuthz propagation in back-ldap

["Pierangelo Masarati" <ando@sys-net.it>]

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

Exactly.  This is done regardless of what's set in
database's config.

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

yes

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

yes

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

this is not currently implemented;

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

this is the case we're dealing with right now.
We are concerned with the identity the proxy
needs to use to forward the client's id to the
remote server (see below).

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

agree

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

As far as I remember, the proxyAuthz control should always
be marked as critical, because otherwise the client could
be misguided on what identity it's taking ... I need to
check te (expired last October) draft...

>
> I think you are suggesting a 5th usage:
>
> 5) Proxy Authenticated, Forward specific identity

Definitely not.  What I'm talking about is what
administrative ideintity to use to proxyAuthz
the client's identity to a remote server who
has no other means to identify a client (case 4).

In my scenario, a proxy is proxying for more than
one remote server, and the client can be authd only
by one of these servers.  So only this remote server
and the proxy know the client is bound.  The mech
I set up uses an administrative identity, that is
present on each of the other remote servers and
is know to the proxy, to propagate the client's
identity to the __other__ remote servers.

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

This would be both dangerous/limiting, because
clients would bind to remote servers either with
more/less privileges, ad we would give up fine
grained ACLs.

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

The proyAuthz draft never mentions bind operations
(not even to explicitly forbid proxyAuthz control
with binds, though)

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

... getting lost :)

>
>
> I haven't thought through all the access control scenarios
> (there are too many).  I presume that remote server will
> do the right thing based on effective authorization identity
> established locally... and the proxy will do the right thing
> based upon the authorization identity established locally.
>
> I don't any need for any special proxy authorization
> and/or access control policy mechanism here.  Guess I'm
> missing something.

There is at least one ACL/security issue: the proxyauthz
identity needs to be able to do authz for the users who
need this privilege.  This requires saslAuthzTo=.* for
the proxyauthz identity, with sasl-authz-policy set to "to"
or "both", which can be dangerous, since everyone else's
saslAuthzTo attr access needs be protected very carefully,
otherwise everybody with write access to its saslAuthzTo
could gain everybody's privileges.

There is no saslAuthzFrom workaround, because the identity
we want the proxyauthz id to assume is by definition not
present in the local database.

Ando.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it