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

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

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
> > > > distributing
> > > > the tree instead of using referrals. In this case, all of
> > > >        
> > the naming
> >    
> >
> > > > contexts
> > > > 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
> >    
> >
> > > > contexts.
> > > >        
>
>  
>
> > 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
> add.
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"
   "uid=proxyadmin,ou=People,dc=my,dc=org"

(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?

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