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