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.