search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
210 stars 90 forks source link

RFC 4511: Proxy authz aci type #1907

Open 389-ds-bot opened 4 years ago

389-ds-bot commented 4 years ago

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/48847

At this time, 389-ds is not correctly in conformance to rfc 4511. Due to the behaviour of the proxy aci, it current operates as:

"Given some target user, allow proxy to any DN over some subtree X".

The issue with this, is that until we are ready to get the results, we cannot send back LDAP_X_PROXY_AUTHZ_FAILURE, and by then we cannot distinguish between a failure to proxy, or a failure for the DN to access the subtree itself.

We should add a new aci type which better expresses the proxy control, and is closer to the rfc.

The new right would be called "authz" rather than proxy. We will need to support both for some time.

The new right would express permissions:

"Given some target (userdn, groupdn), allow proxy to the dn's matched by the target*"

This allows correct setting of LDAP_X_PROXY_AUTHZ_FAILURE early in execution, and would act as a true proxy for object to target. After the proxy right is evaluated and set, then the aci's of the target dn ONLY would need to be checked, rather than the complex double-check we have with the proxy right at this time.

This supercedes and replaces 48367

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-02-11 22:53:18

Metadata Update from @Firstyear:

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-05-05 01:26:22

Metadata Update from @Firstyear:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-04-29 16:32:39

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-04-29 16:36:06

Metadata Update from @mreynolds389:

droideck commented 1 year ago

@Firstyear do you still think it's a good idea?

Just a note that authzid, a SASL proxy authorization, is ignored by the server since proxy authorization is not supported. And we decided to close https://github.com/389ds/389-ds-base/issues/199 as we don't really have a need for that now.

Hence, I have a feeling that it could be confusing to name a new ACI right - authz... We can name it differently though if we still want the feature.

What do you think?

Firstyear commented 1 year ago

This isn't about SASL, it's about our ACI's where you can "proxy" or "impersonate" another user. The way they are implemented has some problems is pretty much what this is about. Saying this, I don't know how common the use of the proxy aci is so .... 🤷‍♀️

droideck commented 1 year ago

This isn't about SASL, it's about our ACI's where you can "proxy" or "impersonate" another user. The way they are implemented has some problems is pretty much what this is about. Saying this, I don't know how common the use of the proxy aci is so .... 🤷‍♀️

Yeah, I understand the feature is not SASL-related.

My first concern was that authz name is associated with SASL already, and it can be a bit confusing that we use it here. I haven't found authz term in the mentioned RFC, so I think we are not bound to it. Or do I miss something?

But yeah, another question will be - if we should spend time on the feature at all...