Authentication Proxy

Table of Contents

To support integration of Evergreen with organizational authentication systems, and to reduce the proliferation of user names and passwords, Evergreen offers a service called open-ils.auth_proxy. If you enable the service, open-ils.auth_proxy supports different authentication mechanisms that implement the authenticate method. You can define a chain of these authentication mechanisms to be tried in order within the <authenticators> element of the opensrf.xml configuration file, with the option of falling back to the native mode that uses Evergreen’s internal method of password authentication.

This service only provides authentication. There is no support for automatic provisioning of accounts. To authenticate using any authentication system, the user account must first be defined in the Evergreen database. The user will be authenticated based on the Evergreen username and must match the user’s ID on the authentication system.

In order to activate Authentication Proxy, the Evergreen system administrator will need to complete the following steps:

  1. Edit opensrf.xml.

    1. Set the open-ils.auth_proxy app settings enabled tag to true

    2. Add the authenticator to the list of authenticators or edit the existing example authenticator:

      • name : Used to identify each authenticator.

      • module : References to the perl module used by Evergreen to process the request.

      • hostname : Hostname of the authentication server.

      • basedn : Location of the data on your authentication server used to authenticate users.

      • authid : Administrator ID information used to connect to the Authentication server.

      • id_attr : Field name in the authenticator matching the username in the Evergreen database.

      • password : Administrator password used to connect to the authentication server. Password for the authid.

      • login_types : Specifies which types of logins will use this authenticator. This might be useful if staff use a different LDAP directory than general users.

      • org_units : Specifies which org units will use the authenticator. This is useful in a consortium environment where libraries will use separate authentication systems.

  2. Restart Evergreen and Apache to activate configuration changes.

If using proxy authentication with library employees that will click the Change Operator feature in the client software, then add "Temporary" as a login_types.

Using arbitrary LDAP usernames

Authentication Proxy supports LDAP-based login with a username that is different from your Evergreen username.

Use case

This feature may be useful for libraries that use an LDAP server for single sign-on (SSO). Let’s say you are a post-secondary library using student or employee numbers as Evergreen usernames, but you want people to be able to login to Evergreen with their SSO credentials, which may be different from their student/employee number. To support this, Authentication Proxy can be configured to accept your SSO username on login, use it to look up your student/employee number on the LDAP server, and log you in as the appropriate Evergreen user.

To enable this feature, in the Authentication Proxy configuration for your LDAP server in opensrf.xml, set bind_attr to the LDAP field containing your LDAP username, and "id_attr" to the LDAP field containing your student or employee number (or whatever other value is used as your Evergreen username). If bind_attr is not set, Evergreen will assume that your LDAP username and Evergreen username are the same.

Now, let’s say your LDAP server is only an authoritative auth provider for Library A. Nothing prevents the server from reporting that your student number is 000000, even if that Evergreen username is already in use by another patron at Library B. We want to ensure that Authentication Proxy does not use Library A’s LDAP server to log you in as the Library B patron. For this reason, a new restrict_by_home_ou setting has been added to Authentication Proxy config. When enabled, this setting restricts LDAP authentication to users belonging to a library served by that LDAP server (i.e. the user’s home library must match the LDAP server’s org_units setting in opensrf.xml). Use of this setting is strongly recommended.