On Mon, Jul 31, 2023 at 03:54:14AM +0000, Jordan Brown wrote: > On 7/30/2023 6:15 AM, Howard Chu wrote: >> If you want an identity to be associated to the session, you perform >> a Bind operation. > > A TLS session with a client certificate is authenticated, whether or not > you do a bind. Slapd ignores that authentication information unless you > do a bind with SASL/EXTERNAL.
A TLS session might be authenticated, but RFC4513 is fairly clear on Bind being used to derive the authenticated identity of an LDAP session, in the case of TLS: "If a client that has provided a suitable certificate subsequently performs a Bind operation using the SASL EXTERNAL authentication mechanism (Section 5.2.3), information in the certificate may be used by the server to identify and authenticate the client." Similar with authorization identity. It later proceeds to state that the authorization state (not identity!) can take into account other factors and is a local matter. This is where ACLs operate and what Sean's proposing to be extended. My answer is that it's wrong to force the ACL subsystem to interact with the connection's TLS/local socket/... contexts where a perfectly good way to do this exists (a Bind request). If you want to add it, a dynacl module is the way, I would personally be open to then merging such a dynacl module into contrib/ but am not volunteering to writing it. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
