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) credentials="manager" mode=self 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 expected.
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.
p.