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

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

> 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.

I think at present we can avoid proxyAuthz'ing bind
operations, I'm implementing a workaround.  I also
note tht in proxy-authz draft there's no mention of
bind operations (not even to prohibte them!)

>
> 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 fact, see my previous message, I'm trying to understand
the implications of adding an administrative proxyAuthz
on top of proxied ldap operations via back-ldap in case
there's already one.  What I've done till now is to leave
the client's one if present.

>
> 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.

Well, this is interesting.

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

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.  But the idea is quite
interesting, and might have other useful applications.

Ando.

>
> 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    |
>> +----------------------------------------------------------------------------+
>>


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