LDAP: Bind user option

[James Fournie]

My reading of the LDAP code is as follows:

1. When a user logs in, a $username is passed to the LDAP code
2. The field $idattr is searched in the LDAP for a value matching $username
3. If this is found, the password is authenticated against the LDAP
4. Return boolean value if auth succeeded or not

Problem:

Let's say I'm a post-secondary library that uses ActiveDirectory. On campus I generally use my LDAP username "jsmith" (ActiveDirectory's sAMAccountName or uid) to login to services. I would like to be able to use this for SSO to Evergreen.

Unfortunately I'm also part of a consortia. Because the consortia contains many users, it's possible that "jsmith" is already taken as a username.

As a workaround we could use barcodes for usernames in Evergreen to avoid username collisions, but it means users will need to sign on with their barcode, whereas they use "jsmith" everywhere else on campus.

Unfortunately, it's not currently possible to easily solve this in Evergreen -- the Evergreen username must be found in an LDAP field.

I'd suggest have two settings:
- the existing $idattr
- another setting let's call $binduser

The initial authproxy should then make a Bind request to the LDAP with the $binduser, and if the Bind succeeds, return $idattr from the LDAP, for use by Evergreen to look up the EG user. (or something like that).

Thus in Evergreen, all my users could have a barcode as a username. The $idattr would be the field in LDAP containing the barcode. However, the $binduser could be sAMAccountName, meaning users would use their regular username to do the actual login.

[Jeff Davis (jdavis-sitka)]

Working branch user/jeffdavis/lp1786552-ldap-bind-user has an untested first pass at implementing this feature:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1786552-ldap-bind-user

[Jeff Davis (jdavis-sitka)]

Force-pushed a small change (scoping issue with $ldap_search var) to the same branch. Works for me in testing.

[Jeff Davis (jdavis-sitka)]

I've pushed an additional commit to the same branch, adding a new "restrict_by_home_ou" setting to auth_proxy config. When enabled, if the login request includes an org param, the authenticator will refuse to authenticate a user unless their home OU matches or is a descendant of that org; login fails and auth_proxy proceeds to the next configured authenticator.

The point of the setting is to provide a safeguard when not everyone in the consortium is using the same authentication proxy. If only Library A is using LDAP, then the LDAP server is only an authoritative auth provider for Library A's users. EG admins may prefer not to allow the LDAP server to authenticate patrons belonging to Library B, Library C, etc.

This is especially important in conjunction with the new "bind user" feature described in this bug report. The new feature allows users to have an LDAP username that is different from their EG username; the Library A user logs in with their LDAP username and the LDAP server provides the corresponding EG username, which EG uses to complete the login. Since the LDAP server is not authoritative for other libraries, it could respond with an "EG username" that is already in use by a user at Library B -- in which case our Library A user would be logged into the Library B user's account! To prevent that, we disallow login unless the logged-in account's home OU is within the scope of the login request's org param. (Note that this does not address the case where no org is specified in the login request; see bug 1715396 for general discussion of that circumstance.)

I've made the restrict_by_home_ou behavior optional because there may be use cases where auth_proxy should be allowed to authenticate users from other libraries. But I think enabling it should be strongly recommended in most situations when not everyone in the consortium shares the same authentication proxy.

[Jeff Davis (jdavis-sitka)]

I've pushed one more update to the working branch related to the restrict_by_home_ou setting. Previously the setting was based on the login org param. But it makes more sense to base it on the authenticator's org units, since that is what tells us which libraries the authenticator is valid for.

[Jeff Davis (jdavis-sitka)]

Release notes pushed to working branch. This is ready for review.

[Galen Charlton (gmc)]

Pushed to master for inclusion in the 3.4 beta. Thanks, Jeff!