Re: proxyAuthz propagation in back-ldap

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

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

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

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

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

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

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

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

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


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.

At 12:12 PM 12/10/2003, Pierangelo Masarati wrote:
>I'm concerned about using the "binddn" identity
>for proxy authz propagation using back-ldap.
>The "binddn" (although the name now appears a bit
>obscure and mileaing) is essentilly intended to
>bypass ACLs on the remote server for proxy internal
>ops.  I'm considering the possibility of using
>different identity for prozy authz.  This because
>the presence of its dedicated administrative dn
>would be used to enable the feature, and this
>should be clearly separated from the need to define
>the "binddn"; moreover, I expect that such user
>should have very specific privileges, generally
>different from those of the binddn:
>
>binddn:
>    - auth permission
>    - essentially read access to *
>
>proxyauthzdn:
>    - auth permission
>    - read access to its own entry's saslAuthzTo
>      attribute, or
>    - read access to others' saslAuthzFrom attribute,
>      for fine grain authz policy
>
>Comments?
>
>Ando.
>
>-- 
>Pierangelo Masarati
>mailto:pierangelo.masarati@sys-net.it