Use case-insensitive search for user lookup by external_auth_id

[stevendanna]

Almost all of the typical values of ldap['login_attribute'] are case
insensitive according to the LDAP schema. However, we previously used a
case-sensitive lookup when trying to find an existing user record.

This commit changes the default lookup to be case insensitive but
provides a user-controllable override for the rare case where users are
setting a case-sensitive login_attribute.

Review Notes

If we were doing this from scratch, I think the correct method of linking LDAP accounts to user records would be to store a canonicalized form of the distinguished name as returned by the LDAP server. Unfortunately, we have live installations with existing data.

I've made case-sensitivity a configurable with a default of false. Most fields that people will use for login_attribute are case insensitive; but it is possible that some users want to use a case sensitive field here. Unfortunately, because of the way chef_db/chef_sql/chef_object are tied together, changing queries based on config either requires adding a new field to the record, or querying the config all the way from chef_user. I opted for the latter as that change seemed to have the smaller surface area.

I looked at the prospect of doing something smarter here such as some sort of data migration combined with a canonicalization of what we store here are the problems I kept running into:

• Data migrations that transform the existing data in the external_authentication_uid column will probably eliminate our ability to use a case-sensitive field for login_attribute.
• Data migrations that change external_authentication_uid to store something such as Distinguished Name require talking to a 3rd party data service, which seems really brittle for large installations.
• Querying the LDAP server for the schema of the login_attribute and changing what we do based on that might be possible but it seems that the exact way to do this might differ between LDAP servers and require our bind user to have permissions that we don't currently require.

[stevendanna]

cc @jeremiahsnapp @stephenlauck @chef/lob

[marcparadise]

The migrate-on-login approach - to canonical name - could work if we keep a 'migrated' flag and use that as part of the query, as SELECT ..., migrated FROM users WHERE (migrated = true AND extid=$1) OR (migrated = false and lower($1) = lower(extid)

[marcparadise]

ldap_case_sensitivity - it's a bit clearer since in context these fetches serve all the different lookup methods.

[marcparadise]

LGTM 👍 after customer confirmation and the function name change.

[stevendanna]

Fixed the function name, thanks for the suggestion. Re the in-place migration. My biggest problem with any migration is just that we don't actually know whether that value should be case insensitive or not without checking the LDAP schema or having the user tell us. If we have the user tell us, I'd rather not do a migration based on that since the user might make a mistake when setting it.