[Date Prev][Date Next]
Re: chaining and proxy
Pierangelo Masarati a écrit :
Guillaume Rousse wrote:
I guess you're referring to syncrepl for multi-master replication
scenarios, right ? In my case, I'm using slapo-chain to allow my user to
change their password, whereas they only access the slave server.
Meaning I only push user-triggered changes to the master. Sorry if I was
not clear enough.
I successfully setup the chain overlay, so as to push changes from a
slave to a master, with something as:
I'm curious, tough, why the slave has to use a proxy identity to
authenticate on the master, instead of reusing original query
credentials. Is there something preventing it, or is just that all
examples I found sofar were using it ?
First of all, in order to do that, slapd-ldap(5), which implements the
chain capability, should know about the details of syncrepl. Second,
the credentials used for syncrepl need to have broad *read* permissions,
while slapo-chain(5) credentials must have broad *authz* permissions.
One might want to use separate identities in order to craft their
permissions appropriately. The fact that slapo-chain(5) is very useful
in conjunction with sync replication is orthogonal to slapo-chain(5)
design. In fact, it was not designed for this purpose.
I was also curious to know if the slapauth tool was usable to test
such kind of proxy setup. Reading the man page, it seems rather
adapted to testing identity mapping through authz-regexp directives.
No. In fact, slapauth only tests authz-rgexp mapping, while what you
want is something similar to authz-regexp but specific to slapd-ldap(5),
and thus buried in its internals. Since it results in an RFC 4370
proxied authorization control, it could be interesting to have a
companion of the RFC 4532 who am I? operation that tells how a DSA is
going to authorize when chaining an operation, and what the who am I?
operation returned after chaining. However, I believe this would only
be useful for "maintenance" checking, as the whole purpose of
slapo-chain(5) is to hide the fact that operations are not handled locally.
OK, thanks for the explanation.
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62