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  and ).