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

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

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

I've reworked things a bit in my devel tree (I'll probably
commit something later) fllowing a different approach.

When a client is authenticated to a proxy server, but the bind
didn't propagate to the reote server (e.g. the authorizing
backend is not the back-ldap) and the "binddn" directive is
present, I made the ldap_back_dobind() routine ldap_sasl_bind()
to the remote server; then, for each operation, and under the
very same circumstances, the PROXY_AUTHZ control is added to
the operation's control.

Each remote server needs appropriate saslAuthz[To|From]
and sasl-authz-policy settings, but this yields the desired
result.

I'm not very comfortable with the point that now an entire
session that would be bound as anonymous is nw bound as
a privilged user, and I have to guarantee that authorization
takes place at every operation.

There are two points I need to solve yet:
1) what happens if the PROXY_AUTHZ control was already
provided by the client?  The mechanism should work, but
the remote server shuld allow authz'ing based on the
real identity of the client, and not on the administrative
identity (binddn); however, there is no way to do that, AFAIK.
2) what to do with operations that must not allow PROXY_AUTHZ
(e.g. extended operations that relate to security, as mentioned
in the proxy-authz draft) or for binds, which are not mentioned
at all in the draft? (by the way, it expired lat October...)

>>
>> saslAuthzTo: *
>
> Should be .* to be a valid regexp.

This is a bit unclear to me; I stepped thru the code,
and it is expeting an URI or a DN which is later treated
as a regex; however, if I use things like

dn:.*

or

dn:uid=[^,]+,dc=example,c=com

they do not pass dnNormalize*(); so I added a "regex:"
prefix which bypasses the DN normalization.  By quickly
browsing the code, this is the only place where such a
"non-standard" prefix is currently of use, o its impact
should be minimal.  Is it acceptable?

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

I think this solution, although simplistic, fixes Tom's
needs (and those of many others, I assume).  Of course,
I need to solve the two problems I describe above (there
could be more).

Ando

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