Michael Ströder wrote:
Howard Chu wrote:Howard Chu wrote:And also an extended op "ExternalBind" for allowing external authentication providers to interact with the existing policy. I.e., this op will supply an LDAP username and a success/fail code to the directory server, and the server will execute the policy mechanisms accordingly. (E.g., if a Fail code is supplied then the failure time and any relevant lockouts are recorded.)Thinking about this some more, I don't think a new exop is the right approach. Instead, I would use a new ppolicy control which can be attached to a Search request. It would only be valid for searches of Base scope. It would result in a ppolicy response control being attached to the search entry that fulfills the search request. This would allow an external authentication mechanism to discover if the account is already locked, password is expired, etc. The response control would also include an opaque cookie.Thinking in this direction a bit further I wonder how requests with Proxy Authz control attached should be handled in case of (temporarily) locked accounts.We would also define a new ppolicy control which can be attached to a Simple Bind request. This control would carry the cookie from the previous response control, and a boolean success/fail value. If the cookie is valid, the credentials of the Bind request will be ignored and the boolean success/fail code is used to update the ppolicy state for the specified user.What's the use-case for that?
I have already dropped this line of thought, so it's a moot point now.I was thinking of SASL, Kerberos, and Samba ("external authentication agents"), which each can use LDAP as an authentication store, but perform the actual credential verification themselves. I wanted the ppolicy control attached to the Search request, to indicate that an authentication was being started. And I wanted the control to be attached to a Bind request, to allow the external agent to tell LDAP what the outcome of the authentication attempt was. This way the directory server can continue to maintain all the policy state thru the Bind mechanism. The external agent cannot simply issue an LDAP Simple Bind because they won't have the plaintext credentials on hand. I wanted a cookie in the control to authenticate that this Bind was a legitimate followon to the earlier Search, to prevent arbitrary clients from sending bogus "Bind/Failed" requests to the directory and thus effortlessly locking out any user of their choice.
But the existing ppolicy spec already allows external authentication, by virtue of the Compare request. After an external agent retrieves the secret and verifies the client, it just needs to do a Compare request to update the directory's policy state. Since it has already retrieved the actual credentials, it can do a Compare with the current value to indicate a successful authentication, and a Compare with some different value to indicate a failed authentication. And the issue of bogus requests is mitigated by using access controls to restrict who can do search/compare on the authentication secret.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www.ietf.org/mailman/listinfo/ldapext