Re: proxyAuthz propagation in back-ldap

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

At 01:59 PM 12/10/2003, Pierangelo Masarati wrote:

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

But assuming you aren't maintaining multiple LDAP sessions
between the proxy and the remote in a particular back-ldap
database instance, you cannot do both bind chaining
and access chaining in the same instance.  Yes?

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

In one database instance per remote?  (Note that
its not really per remote server, but per remote
DIT fragment.  But I'm going to use server below
because it is easier.)

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

Well, that can just be the binddn for second back-ldap
instance, the one associated with the second remote
server.

And if there are users of the second which then chain
to the first, then you need 4 back-ldap instances.

Or, we need to move to two sessions per remote...
or two chaining exops.

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

You kind of get this one free.  Any service which supports
authentication should support assertion of an authzid,
whether its generally useful or not.

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

It's implicitly prohibited.  But since a draft is a work
in progress...

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

But that's not special to back-ldap...

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

Guess I'm confused.  The proxy just assumes it can
assume the identity.  saslAuthzTo/From evaluation would
be done by the remote.  

Kurt