It looks like we currently parse this control, but only to allow logging its contents, and nothing more. Seems like it would be useful to carry the parsed info along with the o_authz struct, and make it usable in the ACL engine. This would allow setting ACLs that can distinguish between different applications acting on behalf of a given user (or service).
Any security downside to this?
On 11/5/19 11:30 AM, Howard Chu wrote:
It looks like we currently parse this control, but only to allow logging its contents, and nothing more. Seems like it would be useful to carry the parsed info along with the o_authz struct, and make it usable in the ACL engine. This would allow setting ACLs that can distinguish between different applications acting on behalf of a given user (or service).> Any security downside to this?
If the LDAP client got hacked the content of the control value cannot be trusted. So security considerations similar like with proxy authz apply.
Anyway I'd like to have it available also in set-based ACLs.
Furthermore I'd like to have normal peer address available in set-based ACLs e.g. to grant auth access to userPassword only to bind requests coming from a certain IP address stored in the attribute of a user's entry (e.g. 'aeRemoteHost' in Æ-DIR [1] and [2]).
Ciao, Michael.
[1] https://www.ae-dir.com/docs.html#schema-oc-aeUser-attributes
[2] https://www.ae-dir.com/docs.html#schema-oc-aeService-attributes
-
Howard Chu -
Michael Ströder