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

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

I'm switching to -devel ...

Howard Chu wrote:

-----Original Message-----
From: Pierangelo Masarati [mailto:ando@sys-net.it]

Tom Riddle wrote:

Howard Chu wrote:

If you're using OpenLDAP 2.1 or newer, you can use back-ldap for
the tree instead of using referrals. In this case, all of

the naming

will be defined on all of the servers, but some portions

will be local

databases and some portions will be proxied via back-ldap. So in
effect all
of your binds will always be contained within any of the

servers' naming


As Tom and I discussed privately, what's basically needed here
is a mechanism, totally transparent to the client, that allows
a system administrator to set up the distributed DSA in such
a way that when a client authenticates to either of the servers,
its credentials are automatically propagated to those members
of the distributed DSA where operations need to be propagated:
a sort of authorization mechanism.  This could be done easily
by means of a control that allows a proxy to connect to a remote
server with an administrative identity and ask the remote server
to replace this identity into that of the client that initiated the
operation.  The remote server must trust the administrative
identity (e.g. there must be some permission mechanism that
allows one identity to become another "lesser" identity; the
easiest way would be to set up a static "proxydn" in the database
portion of slapd.conf, but we could also think of some new acl
permission, or recycle the auth permission).

So, as soon as a client binds to the proxy, and requests an operation
that needs propagation to a remote server, the proxy should bind
to the remote server with the administrative identity, authorize
the client's identity, and reserve that connection to operations for
that client.

To summarize:

at the proxy side:
- a (client-side) control on top of bind to change identity

at the remote server side:
- a (server-side) control on top of bind that changes identity
 if permitted;
- a simple permission mechanism, e.g.:
 * expand ACL auth permission semantics
 * introduce a new ACL permission (su?)
 * use a static "proxydn" statement in slapd.conf

I hope I'm not reinventing the wheel, though: thinking about
the proxyauth mechanism.

You'll see that I went down pretty much this path on openldap-devel several months ago. But the notion of a proxyAuth control for Bind was rejected.

I've seen that.  And I think it is required for this purpose.
I agree it might be dangerous if configured as such to let
normal users do bind authorization, but it can be an
important brick in  building distributed systems.

The OpenLDAP 2.2 back-ldap can handle most of what's needed here, since it
supports connection sharing already. The only piece missing is the use of the
proxyAuth control for the proxied requests, which shouldn't be too hard to

I concur.

Proxy authorization policy is already controlled using the sasl-authz-policy
directive and its associated attributes. I don't see any reason to introduce
a new permission mechanism here.

I understand and totally agree; my only concern is that this feature should require as little changes to the data as possible (preferably none). So, if I understand, to allow an administrative identity to perform authorization on behalf of every DN in the remote server's tree, the following rule should be enough:

sasl-authz-policy to
sasl-regexp "uid=proxyadmin,cn=plain,cn=auth"

(replace whatever mechanism and whatever
administrative identity you want to use) and the
"uid=proxyadmin,ou=People,dc=my,dc=org" entry
should contain an AVA

saslAuthzTo: *

to allow "uid=proxyadmin,ou=People,dc=my,dc=org" to take
whatever identity, isn't it?

|   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax:+390382476497    |