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

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

I could see the proxyAuthz control being used with LDAP simple
bind much as many SASL mechanisms support identity assumption.
However, we should be clear that the purpose of the bind is to
establish an authentication association (and associated
authorization identity) between the LDAP client and server.

One of the problems using the proxyAuthz control in chaining
(between servers) is that it interferes with clients own use
of the control between the client and the directory.

In hallway discussions at IETF#58, we concluded that LDAP
really needs to have a "chaining" operation which would wrap
the client request when it was chained to another server (much
like in X.500).  This would provide a clear separation between
client's desires and chaining server's desires.

A client's bind to the directory could be chained.  When chained,
the chaining server could provide additional information necessary
for the chained server to properly respond (think man-in-middle
detection) and for the chaining server to learn the client's
identity established at the chained server.

Comments?

Kurt

At 05:56 AM 11/29/2003, Pierangelo Masarati wrote:
>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    |
>+----------------------------------------------------------------------------+