Re: proxyAuth for bind (Was: Can I bind to server with DN not on server ?)

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

> At 06:55 AM 11/30/2003, Pierangelo Masarati wrote:
>>In the present case, I think this is an overkill, thou.
>>I think we don't really need to have binds chained; if
>>proxyAuthz allows to propagate other operations with
>>an identity, this is enough.
>
> I think we'll need to distinguish whether its the client
> or the chaining server or both which is requesting proxy
> authorization.  Error handling will be really hairy if we
> don't.

I see your point; I might be interested in looking at it,
if there is any definition. in the meanwhile, I've committed
a couple of changes, protected under #ifdef LDAP_BACK_PROXY_AUTHZ,
that (if defined) automatically use the "binddn" identity
to bind to remote servers if no direct bind resulted from
client's operations, and add the client's credentials to
each operation in form of proxyAuthz control, if not present.

This allows to set up pools of servers with branches of a
common naming context, and operate on each of them in
perfect symmetry (from the client's standpoint).  Of course,
a small document on how to obtain this might be useful, and
a test suite might even be more useful, because it's not so
straightforward.  I think Tom will better test it for all,
since he started the discussion ;).

Tom,

you need to set up one server with

# on server A:

database ldap
suffix "o=B,c=US"
subordinate
uri "ldap://serverB";
lastmod off
binddn "cn=ProxyAuth,o=B,c=US"
bindpw "secret"

database ldap
suffix "o=C,c=US"
subordinate
uri "ldap://serverC";
lastmod off
binddn "cn=ProxyAuth,o=C,c=US"
bindpw "secret"

database bdb
suffix "c=US"
# will contain branch "o=A,c=US" as well
# ...

# "both" is fine as well
sasl-authz-policy to

# create at least "cn=ProxyAuth,o=A,c=US" entry,
# give it the appropriate permissions, and add
# "saslAuthzTo: regex:.*" or equivalent more
# granular authorization mapping

# on server B:

database bdb
suffix "o=B,c=US"
# ...

database ldap
suffix "c=US"
uri "ldap://serverA";
lastmod off
binddn "cn=ProxyAuth,o=A,c=US"
bindpw "secret"

# "both" is fine as well
sasl-authz-policy to

# create at least "cn=ProxyAuth,o=B,c=US" entry,
# give it the appropriate permissions, and add
# "saslAuthzTo: regex:.*" or equivalent more
# granular authorization mapping

# on server C:

database bdb
suffix "o=C,c=US"
# ...

database ldap
suffix "c=US"
uri "ldap://serverA";
lastmod off
binddn "cn=ProxyAuth,o=A,c=US"
bindpw "secret"

# "both" is fine as well
sasl-authz-policy to

# create at least "cn=ProxyAuth,o=C,c=US" entry,
# give it the appropriate permissions, and add
# "saslAuthzTo: regex:.*" or equivalent more
# granular authorization mapping

Note that the behavior is symmetric in the sense that
any operation, with any identity, can be initiated
at any of the servers with identical result (if it's
not, then it's a bug; let me know).

However, the server-side activity is not symmetric at all:
operations that span the whole distributed tree are
better initiated at serverA; if, say, you search "c=US"
starting from serverB, then the request is proxied to
serverA and the branch on serverB itself is proxied
back, resulting in unnecessary traffic.  But all of this
is totally transparent to the client.

I've tested it with all the operations: add, delete,
modify, modrdn, search, compare and passwd_extop.
Of course, if you do more than simple searches, you'll
need more sophisticatd ACLs.

Ando.

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