Hey Michael,
I would assume that for the proxy it shouldn't matter how the client got authenticated to the consumer. Mode=self should just try and assert the resulting authzID to the target. The identity of the proxy is only there so we have something to bind with to the producer. With mode=none, that identity would also be used for the actual ACL evaluation, but that would just lead to all writes being done by seemingly 1 user, making auditing impossible ...
Cheers, //Dieter
On Fri, 6 Mar 2020 at 13:00, openldap-technical-request@openldap.org wrote:
---------- Forwarded message ---------- From: "Michael Ströder" michael@stroeder.com To: openldap-technical@openldap.org Cc: Bcc: Date: Thu, 5 Mar 2020 21:46:12 +0100 Subject: Re: back-ldap SASL proxy authorization On 3/5/20 9:04 PM, Howard Chu wrote:
Dieter Bocklandt wrote:
I would assume the following takes place:
- The service user binds to the consumer and assumes dieter's identity,
which should be the same net effect as binding with dieter's user in the first place.
- The proxy user binds to the provider and assumes dieter's identity
- The provider tries to perform the write, using dieter's identity for
ACL evaluation
What actually happens:
- The service user binds to the consumer and assumes dieter's identity
- The proxy user binds to the provider and assumes the service user's
identity
- The provider tries to perform the write, using the service user's
identity for ACL evaluation
Actually, I spent some more time on this today and I /think/ I might
know what's happening here:
Your analysis makes sense. Would have to ask Pierangelo why he wrote it
the way he
did but it seems that it should use op->o_ndn.
Hmm, is the semantics of proxying the SASL proxy authorization clearly defined? The consumer proxy itself also has an identity.
Just asking...
Ciao, Michael.
openldap-technical mailing list openldap-technical@openldap.org http://www.openldap.org/lists/mm/listinfo/openldap-technical