RE: proxyAuthz propagation in back-ldap

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

>>> (note: if the client itself provides a proxy control,
>>> the proxy should reject the operation (e.g., not chain it)
>>> (possibly returning 'referral').  Also, each proxy generate
>>> proxy control should be marked critical.)
>>
>>I'm not sure why this is required. The draft spec does not prohibit
>> multiple instances of this control from appearing in a request.
>
> Because the draft doesn't say what the semantics of multiple
> controls.
>
>>Currently if slapd
>>receives multiple instances, they will be processed in order.

currently, parseProxyAuthz() fails if proxyAuthz is specified
more than once; the client tools don't let you specify it more
than once as well.


In some sense, specifying it more than once could be specified
as (but it's not stated anywhere) that:

- client identifies with its id (bind_id)
- the server authzs the operation with id of control 1 (id_1),
  based on the permissions of bind_id (access to
  saslAuthzTo of bind_id by self and its contents
  of saslAuthzTo/saslAuthzFrom) and id_1 (access to saslAuthzFrom
  of id_1 by bind_id and its contents)
- for each subsequent (k-th, k=1:n) instance of the control,
  the server authzs the operation with id_[k] based on the
  permissions of id_[k-1] (access to saslAuthzTo of id_[k-1]
  by self and its contents) and id_[k] (access to saslAuthzFrom
  of id_[k] by id_[k-1] and its contents)

This could be shunted by going from bind_id to id_[n] directly,
at the price of compromising security.  That's what concerns me
about doing operation proxyAuthz in back-ldap when the control
is already present.  I currently chose to leave the original
proxyAuthz in place, if any, because otherwise I would break the
symmetry of the pool of servers (same result regardless of what
server is contacted first).

>
> But the specification defines no semantics of their order.

If desirable, we could define it the way I indicated above

>
>>As such, if the
>>client-supplied proxy control is handled after the back-ldap inserted
>> proxy control, the result will be as desired.
>
> The problem here is that the proxy has no way to tell which
> control failed if the remote reports a proxy authorization
> error.

Well, in either case the failure would be critical, because
if the proxy side instance of the control fails, the
client-supplied can't be performed anyway, so treating it
as a generic proxyAuthz failure wouldn't hurt.

If we decide for applying multiple proxyAuthz in order, and
we define the ordering rules, e.g. as above (and we handle
the single control as is today, thus not breaking any existing
implementation) the implementation should be straightforward.

Of course this is not a general solution.

Ando.

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