Full_Name: Andrew Findlay Version: 2.4.10 OS: Linux: SuSE 10.2 URL: Submission from: (NULL) (88.97.25.132) When using "authz-policy to" I find that the entity that is trying to do an operation on behalf of another entity needs read access to its own authzTo attribute. This seems wrong: authzTo is defining what the user may do: I do not really want them to be able to see it. When doing a proxy authz I think ACLs for this attribute should not be checked at all as the access is effectively being done by the rootdn.
changed notes
andrew.findlay@skills-1st.co.uk wrote: > When using "authz-policy to" I find that the entity that is trying to do an > operation on behalf of another entity needs read access to its own authzTo > attribute. > This seems wrong: authzTo is defining what the user may do: I do not really want > them to be able to see it. When doing a proxy authz I think ACLs for this > attribute should not be checked at all as the access is effectively being done > by the rootdn. AFAIK, access to that attribute is checked using AUTH rather than read. The idea is that ACLs should allow to fine-grain control who is allowed to exploit the authorization feature while giving up as little as possible (e.g. AUTH instead of READ). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it -----------------------------------
On Sat, Jun 14, 2008 at 03:59:37PM +0200, Pierangelo Masarati wrote: > AFAIK, access to that attribute is checked using AUTH rather than read. > The idea is that ACLs should allow to fine-grain control who is > allowed to exploit the authorization feature while giving up as little > as possible (e.g. AUTH instead of READ). You are right: if I just grant 'auth' access to 'authzTo' the proxy authorisation succeeds. The philisophy makes sense so I will try to come up with a suitable patch to the Admin Guide describing how to use it. At the moment the only note about this is in the ACL Examples (7.2.5 at present) which says that authentication/authorization is always done anonymously - obviously not entirely true. I am still a bit worried about the logic of the access test, as in my enviroment I just had to grant the principal auth access to their own authzTo attribute to make proxy authorization work: the principal does not even have 'disclose' access to their own entry or the parent entry. Normally I would expect to need some level of access to everything in the DN before I could make use of an attribute in an entry. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
andrew.findlay@skills-1st.co.uk writes: > You are right: if I just grant 'auth' access to 'authzTo' the proxy > authorisation succeeds. The philisophy makes sense so I will try to > come up with a suitable patch to the Admin Guide describing how to use > it. At the moment the only note about this is in the ACL Examples > (7.2.5 at present) which says that authentication/authorization > is always done anonymously - obviously not entirely true. If non-anonymous access is needed, the slapd.access(5) manpage needs an update too. (Or instead, to avoid duplicating text.) Currently it just says: Auth (=x) privileges are also required on the authzTo attribute of the authorizing identity and/or on the authzFrom attribute of the authorized identity. but it doesn't mention to who needs that auth access. -- Hallvard
On Mon, Jun 16, 2008 at 02:45:43PM +0200, Hallvard B Furuseth wrote: > If non-anonymous access is needed, the slapd.access(5) manpage needs an > update too. (Or instead, to avoid duplicating text.) Currently it just > says: > > Auth (=x) privileges are also required on the authzTo attribute > of the authorizing identity and/or on the authzFrom attribute of > the authorized identity. > > but it doesn't mention to who needs that auth access. It is the authenticated ID that needs access in both cases. On further thought I think it is correct that the access is checked without reference to whether that ID has access to entry and parent entries, as (particularly in the case of authzFrom) the authenticated ID may not have any direct access to the entry whose ID it is about to assume. Thus, if principal A has authenticated and wishes to perform an operation using principal B's authorisation, the access required is: A needs auth access to authzTo in its own entry if that attribute is involved in giving A permission to act for B. A needs auth access to authzFrom in B's entry if that attribute is involved in giving A permission to act for B. The rules are the same whether using a SASL authorization identity or using a ProxyAuth control on an LDAP operation. Thus I think my original report was wrong. This is a documentation issue, not a bug. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
moved from Incoming to Documentation
On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote: > Thus I think my original report was wrong. This is a documentation > issue, not a bug. I have uploaded a suggested set of patches to make the behaviour clearer: ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch The patch is against 2.4.10 It might be better still to factor out the concept of proxy authorisation and its control from the SASL authz mechanism, as it applies also to the LDAP Proxied Authorization Control. I have not done this as I was unsure where best to put it. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
andrew.findlay@skills-1st.co.uk wrote: > It might be better still to factor out the concept of proxy > authorisation and its control from the SASL authz mechanism, as it > applies also to the LDAP Proxied Authorization Control. > I have not done this as I was unsure where best to put it. Not sure what you mean there, but I believe the fact that the implementation is in saslauth.c is for mere historical reasons. Right now, authorization code is independent from SASL, and is used by a number of features: SASL authz, RFC 4370, identity assertion, dgIdentity and more. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it -----------------------------------
On Mon, Jun 16, 2008 at 07:29:12PM +0200, Pierangelo Masarati wrote: > Not sure what you mean there, but I believe the fact that the > implementation is in saslauth.c is for mere historical reasons. Right > now, authorization code is independent from SASL, and is used by a > number of features: SASL authz, RFC 4370, identity assertion, dgIdentity > and more. I was referring to documentation, where the only bit of the admin guide that really talks about proxy authorisation is the SASL section. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
Andrew Findlay wrote: > I was referring to documentation, where the only bit of the admin > guide that really talks about proxy authorisation is the SASL section. Ah, OK. Note that since some point in 2.3, authorization is described by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, which should probably be advertised a bit more (and moved out from the experimental OID arc). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it -----------------------------------
On Mon, Jun 16, 2008 at 08:06:17PM +0200, Pierangelo Masarati wrote: > Ah, OK. Note that since some point in 2.3, authorization is described > by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, > which should probably be advertised a bit more (and moved out from the > experimental OID arc). If that is used *everywhere* for authorisation then there could well be more doc errors to correct. I am fairly sure I saw one place where the docs specifically exclude some of those forms. I notice that '*' excludes anonymous in this spec. There is an undocumented option to 'allow' that seems relevant: proxy_authz_anon - would allowing this cause anon to be included in '*' generally or is it not that simple? Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
andrew.findlay@skills-1st.co.uk wrote: > On Mon, Jun 16, 2008 at 08:06:17PM +0200, Pierangelo Masarati wrote: > >> Ah, OK. Note that since some point in 2.3, authorization is described >> by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, >> which should probably be advertised a bit more (and moved out from the >> experimental OID arc). > > If that is used *everywhere* for authorisation then there could well > be more doc errors to correct. I am fairly sure I saw one place where > the docs specifically exclude some of those forms. Yes, I believe in some cases some of the variants of the syntax are not allowed. This is true, for example, in SASL identity mapping, which does not allow the regex, subtree, children, onelevel, group and users styles, only the base and uri forms are allowed (provided the latter only returns a single match). > I notice that '*' excludes anonymous in this spec. There is an > undocumented option to 'allow' that seems relevant: proxy_authz_anon - Why undocumented? It is documented (in 2.4, at least; it does not exist for 2.3). > would allowing this cause anon to be included in '*' generally or is > it not that simple? '*' implies a non-empty value; to include anonymous, use "dn.regex:.*", or "dn.subtree:". p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it -----------------------------------
> On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote: > >> Thus I think my original report was wrong. This is a documentation >> issue, not a bug. > > I have uploaded a suggested set of patches to make the behaviour > clearer: > > ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch > > The patch is against 2.4.10 > > It might be better still to factor out the concept of proxy > authorisation and its control from the SASL authz mechanism, as it > applies also to the LDAP Proxied Authorization Control. > I have not done this as I was unsure where best to put it. Hi Ando, If you get a chance at some point, could you review this patch and I'll apply it etc. Thanks, Gavin.
Gavin Henry wrote: >> On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote: >> >>> Thus I think my original report was wrong. This is a documentation >>> issue, not a bug. >> I have uploaded a suggested set of patches to make the behaviour >> clearer: >> >> ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch >> >> The patch is against 2.4.10 >> >> It might be better still to factor out the concept of proxy >> authorisation and its control from the SASL authz mechanism, as it >> applies also to the LDAP Proxied Authorization Control. >> I have not done this as I was unsure where best to put it. > > Hi Ando, > > If you get a chance at some point, could you review this patch and I'll apply it > etc. After a quick look, it seems to be a good starting point. I'd be a little bit more careful about wording: "proxyAuthz" should probably be "proxied authorization"; the first time it is mentioned, a reference to RFC4370 should be present, both in slapd.access(5) and in the Admin Guide (as in the SASL section). Also, in the contribution to the Admin Guide it is sometimes referred to as the "proxy facility"; I'd rather use "proxied authorization facility" or better "proxied authorization control". Finally, the patch seems to correctly explain what is required in order to authorize. I'd add a strong comment on the importance to protect authzFrom and especially authzTo from malicious writes, that could result in lesser privileged identities to modify their own entry in order to be able to self-authorize as higher privileged identities. Administrators should be warned as they start reading about this feature. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
feature requires AUTH rather than READ
Created attachment 830 [details] 20080616 proposed patch
https://git.openldap.org/openldap/openldap/-/merge_requests/360
Commits: • 73e7034d by andrew.findlay@skills-1st.co.uk at 2021-07-26T22:02:55+00:00 ITS#5555 - Correct documentation for SASL AuthzTo Check