[Date Prev][Date Next]
RE: proxyAuth for bind (Was: Can I bind to server with DN not on server ?)
> -----Original Message-----
> From: Pierangelo Masarati [mailto:firstname.lastname@example.org]
> >>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
> >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.
I'm not sure it's such a dangerous thing. Following the X.500 DSP model - the
proxy server Binds as a privileged user to the remote server. When a client
Binds to the proxy, what you really want to happen next is for the Bind to be
forwarded over the proxy session and executed, but without altering the proxy
session's privileged authorization state. I.e., you want the Bind
verification to be done, but leaving the session with the proxy server's
original authorization when it's finished. It seemed to me that the NoOp
control would encompass this functionality perfectly well.
In the absence of this Control support, you can still manage it using a
second LDAP session reserved exclusively for Bind requests. Aside from the
basic clumsiness of this approach, you're stuck handling a single Bind at a
time (synchronously) since the normal Bind behavior causes all outstanding
operations on a session to be Abandoned.
The other point about this is that it's only necessary for Simple Binds. We
can handle SASL Binds already, because slapd's internal Auxprop module can
handle things transparently.
> >Proxy authorization policy is already controlled using the
> >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: *
Should be .* to be a valid regexp.
> to allow "uid=proxyadmin,ou=People,dc=my,dc=org" to take
> whatever identity, isn't it?
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support