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

Re: Propagation of proxyAuthz control

Javier Manteiga wrote:

We are trying to set a system with the DIT split in several servers,
using the Meta backend to proxy the LDAP requests among them. In the
remote servers we would like to check the ACLs using the identity of the
client that sent the request, instead of the identity used to create the
proxy connections. For this we have configured the idassert parameters
in the meta targets as follows:

idassert-bind bindmethod=simple
              binddn="cn=manager,dc=operator,dc=com" (root user of the
backend receiving the proxied query)
iddassert-authzFrom "dn:*"

When the first proxy is made everything is OK. The proxyAuthz extension
control is added to the LDAP message and the remote server behaves as

Our problem is that in some cases we have requests that must be proxied
several times. E.g: consider a scenario with three servers in A, B and
C. in which the LDAP request sent by the external client is received in
A, this server proxies it to B. Finally B proxies it to C. When B tries
to set the proxyAuthz control it detects that there is already one and
it returns the error "proxyAuthz not allowed within namingContext".

Is there anyway in which we can avoid this error and propagate the
credentials of the external client to the last server?.

No. If you use proxyAuthz to propagate the client's identity to a remote server, then the remote server cannot use the same trick to propagate what it believes the client's identity, while it's actually the first proxy's identity. By design we decided to disallow nested identity assertion.

This mechanism requires distributed procedures, where any control like proxyAuthz would be wrapped by procedure distribution information, thus allowing nested chaining and so. This was discussed long ago when chaining and identity assertion were first implemented. The I.D. about distributed procedures expired long ago, and was never revitalized, so this functionality is not available.