Sean Gallagher wrote:
On 28/07/2023 12:35 pm, Howard Chu wrote:
Clients that don't Bind are, by definition, anonymous.
Yes, that is the term used in the RFCs, but the RFCs do not say what anonymous sessions can and cannot do. This is up to the system administrator. It is not unreasonable to base those permissions on who by or how the connection was established.
Compare: access to dn="ou=people,o=Example Corp" attr="userPassword" by externalself auth access to dn="ou=people,o=Example Corp" attr="userPassword" by anonymous auth
clearly not exactly the same
Clearly pointless, because an external bind doesn't need access to userPassword at all.
Think SIMPLE bind over an ldaps channel. Just because the EXTERNAL identity is there, does not force a client to use it.
The analogy fails because "auth" access doesn't allow a user to see the values of what access was granted to, while anyone could read the contents of the passwd file. Granting auth access only allows clients to perform Simple Bind ops.
Not a perfect analogy, but still helpful.
You are asking to associate an identity to a session. That is what "authenticating" is. In LDAP a Bind request is used for authentication.
You're asking for LDAP to perform some new, previously undefined operation to do exactly what a SASL EXTERNAL Bind does.
This is not a new or undefined operation, this is as old as computers themselves. I control who my clients are by who I allow to connect to my system. Signing a certificate for a client is the modern day equivalent of "plugging it in". The fact that LDAP has an explicit bind operation does not invalidate this fundamental rule of computer networks.
Regardless. A session is either authenticated, meaning it has an identity associated to it, or it is anonymous, meaning it has no identity associated to it. You can't have both at once. If you want an identity to be associated to the session, you perform a Bind operation. End of story.