OpenSC/pam_pkcs11 — pull request #6 by nalind (2014-08-27 21:58:40+00:00)
Title: Changes (most of them optional) to how the LDAP mapper does matching

I've been prototyping some changes aimed at making the LDAP mapper faster and more flexible, and I'd like to know if you agree with them.

* Currently, to check for a match, we construct a filter, locate an entry using that filter, and directly compare its userCertificate attribute values to the card's certificate. If we encode that test as part of the search filter, a server that indexes the attribute will return 0 results, and we can skip parsing and comparing the certificates.
* When we need to find the matching user, we currently enumerate all of the users, looking up their entries, and checking each one in turn. While this lets us match against entries where the user's name is a substring in an attribute value (for example, the initial portion of an email address where we know the domain name), I don't know how frequently that sort of flexibility is needed. If we instead use a wildcard in place of the user name in the configured search filter, but still pass the certificate in the filter, we can search the whole directory once and find the right entry. If we can then read the user's login name from a second attribute in the entry, we can find usually find the user in less time than we did otherwise. Configuring the new "uid_attribute" setting will switch to that behavior.
* When we go to search the directory, instead of only being able to match on the entire certificate being present in an attribute, I've seen requests from deployments where the LDAP entry contains only one of the pieces of information that's present in the certificate (a UPN value in the krbPrincipalName attribute, for example). The last couple of patches add a method for specifying alternate criteria which should be used to locate the user's entry, and uses those settings to alter the filter that's used for looking up the user's entry. If left unset, the current test (as modified by the first change described) continues to be used.

If those sound good, but the patches don't look right, I'm happy to make changes. If not, it's back to the drawing board. Thanks!