Howard Chu wrote:
Also, for Heimdal, I thought one of the benefits of using ldapi was that you could have more privileged access to the LDAP data without having to store authentication credentials and use them as would be used when accessing over TCP.Yes. But again, the Heimdal KDC does an explicit SASL/EXTERNAL Bind to request this privilege. There is no assumption of automagic authorization. Even though the credentials are available, the server will not inspect them unless it receives a SASL/EXTERNAL Bind request. If it receives such a request, then it will construct a SASL authentication DN of the formgidNumber=GID+uidNumber=UID,cn=peercred,cn=external,cn=authwhich then drops into the usual SASL identity mapper for optional munging into some other DN and that DN becomes the identity bound to the session.
I guess we can add that. Rich and I have already talked about that as a TBD.
Note that RFC4513 section 4 states explicitly : Upon initial establishment of the LDAP session, the session has an anonymous authorization identity.
Right. Note that this is an option, it can be turned off.
Section 2 also states LDAP server implementations MUST support the anonymous authentication mechanism of the simple Bind method (Section 5.1.1).I think it's clear that an anonymous bind MUST actually give you an anonymous session state, not some other implicitly selected identity.
The server does support the anonymous authentication mechanism ;)While observing RFC4513 is a good thing, and this implementation does so when auto-bind is switched off, I believe these kinds of decisions are the domain of site administrative policy and not of standards documents. Further, a client in the anonymous bind state has no practical knowledge of the effects of that state on server responses in any case, nor can it be sure that binding as a non-anonymous user has any effect on those responses, nor indeed does auto-bind necessarily remove or add any privilege for the client - that is all administrative policy and undefined by any RFC. This is just one more administrative policy option.
In addition, LDAP is defined as it is in no small part to the underlying assumption of TCP and designed around the practical methods of authentication given that assumption, strictly speaking LDAPI isn't LDAP (it's not even platform agnostic), and LDAPI has other methods at its disposal.
While I understand your concern, the feature is an option, not a requirement.
-- Pete
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
