Single Sign-On Authentication Options for Koha

Single Sign-On Authentication Options for Koha

Koha offers several options for using external authentication services to allow users to sign in.

Basics about SSO

For setting up any SSO there are a few things that will make the process proceed smoothly:
  1. Communication between the partner and their IT departments and direct communication between ByWater and IT
  2. In the case of any SSO that must be setup on the Koha backend we are greatly aided by being able to directly communicate with the staff configuring the server at the partner end
  3. Test accounts
    1. If ByWater is provided a test account that mirrors a real account as closely as possible we are able to test and debug any issues in a timely fashion. This is important both during initial setup and later troubleshooting.
  4. Partner input
    1. Many of the decisions about SSO (what fields are needed, what will be used to match accounts) are up to the partner and will need to be discussed/chosen by the relevant staff

Local sign on

No SSO method prevents local sign on. Koha accounts can have their own username/password - if they do then SSO can be avoided. This is useful for library staff accounts who may not be in the SSO database, and allows a backup access in case there are issues in the SSO connection.

For general users it is important to prevent users from being able to set/change their Koha password, otherwise they can have a direct Koha password that would allow access even if the SSO record is removed.

As of 19.05 it will be possible to allow select categories to change their password (local users) and prevent other categories from doing so (remote/SSO users)

When loading patron we suggest either blanking the password field, or filling it with a random string to prevent end users from circumventing SSO.

Combining methods

All of these options work independently, and more than one method may be enabled for any site.

Self registration

None of the methods prevent the use of patron self registration, in the same way that local login is always allowed, if self registration is enabled users can still sign up for local accounts directly through Koha. No information will be passed to the SSO for these accounts unless an export of these accounts is setup.

Auto-provisioning / Account creation

Several methods support creating accounts when a user exists externally but not locally in the Koha database. There are few things to note:
  1. Users will not be created until they have signed in.
    1. Generally we recommend performing regular patrons loads so that users can circulate items without having signed in to the catalog beforehand. We do not currently harvest users from any SSO sources.
  2. Users are required to have a category and branchcode set to valid system settings
    1. Users must be assigned these values on creation - we cannot alter the data received from the SSO source so they must either have direct matches between Koha and the SSO, or be assigned to a default branch/category - usually we setup something like 'SSOUSER' so that these accounts can be identified and fully populated on the next load or by library staff
  3. Any information the library needs in these accounts must be sent by the SSO
    1. When creating the account we can only populate with information we are given. It is up to the library to determine the fields required and up to IT to ensure those fields are sent

Account updating

Koha does support updating local accounts with the data retrieved from the SSO. As above, only fields passed by the SSO can be updated, and the data cannot be manipulated, it will be copied directly.

Unless there is an exact match between category/branchcode one cannot enable both auto-provisioning and auto-update - if you do then all users will be reset to the default category specified for creation upon each sign-on.

LDAP

LDAP allows patrons to use the built-in Koha sign in form. Users will enter their username and password - these credentials are the used to look up and match a user in the LDAP server. If an LDAP user is found we then search for a corresponding Koha user and log them in if found. If the ldap lookup fails, or the credentials don't match, the username and password are then checked against the Koha database directly and the user is signed in if the credentials are valid

Setup

This is done on the backed by Bywater staff in coordination with library IT

Account creation

Yes - see 'Auto-provisioning' section

Account update

Yes - see 'Auto-provisioning' section

SAML

When SAML is enabled a new link for 'Shibboleth sign on' is added to the Koha system. Users with a SAML account will click this link, be directed to your sign on solution, and then checked against existing Koha users. Local sign on is still an option, however, we can hide or customize the login form to highlight SSO or hide local links

Setup

This is done on the backed by Bywater staff in coordination with library IT

Account creation

Yes - see 'Auto-provisioning' section

Account update

Yes - see 'Auto-provisioning' section

CAS

When CAS is enabled a new link is added to the Koha sign in form. Users with a CAS account will click this link, be directed to your sign on solution, and then checked against existing Koha users. Local sign on is still an option, however, we can hide or customize the login form to highlight SSO or hide local links

Setup

CAS can be setup by the library directly by populating the system preferences
  1. casAuthentication - Yes/No to enable/disable the service
  2. casLogout - Yes/No to log the user out of the CAS server when they logout of Koha
  3. casServerUrl - A full URL to the CAS server

Account creation

Not supported at this time

Account update

Not supported at this time

Google OAuth

When Google OAuth is enabled a new link is added to the Koha sign in form. Users with a Google account will click this link, be directed to your sign on solution, and then checked against existing Koha users. Local sign on is still an option, however, we can hide or customize the login form to highlight SSO or hide local links

Setup

OAuth can be setup by the library directly by populating the system preferences
  1. GoogleOpenIDConnect - Yes/No to enable/disable the service
  2. GoogleOAuth2ClientID - Find in your Google account
  3. GoogleOAuth2ClientSecret - Find in your Google account
  4. GoogleOpenIDConnectAutoRegister - Enable auto-provisioning
  5. GoogleOpenIDConnectDefaultBranch - Branch to use for auto-provisioning
  6. GoogleOpenIDConnectDefaultCategory - Category to use for auto-provisioning
  7. GoogleOpenIDConnectDomain - Limit users to a single google domain

Account creation

Yes - unlike other services, google will only populate name and email, and users must be assigned to a default branch/category supplied in the preferences as described above.

Account update

Not supported at this time

Ebsco services

EDS/OpenAthens both have koha plugins that support connecting the catalog to these resources. OpenAthens can allow users to sign in once and access various external databases as configured in OpenAthens. It is worth noting these here as they are often a concern for SSO solutions. OpenAthens also supports the SAML protocol as an SSO itself

Can a Library Use a Mix of Institutional Single Sign-On and Library Credentials for Catalog Log-in?

Libraries will frequently use single sign-on (SSO) for library staff. For libraries that have a very defined user base like a research or academic library, they may opt to use SSO for OPAC/public access as well. However, even these institutions may have a combined user base where some patrons may have library accounts but not be a member of the institute, like some alumni, reciprocal borrowers, or other 'guest' account types.

Libraries can customize the login for both Koha OPACs and Aspen Discovery so that they accept a combination of SSO users as well as patrons logging in with just their library credentials.

    • Related Articles

    • Koha Calendar Options

      Calendars play a part in our everyday workflow. From events to who is covering the desk and more. This article covers everything from the staff interface to the OPAC. The calendar plays a centerpiece of the Koha Administration. Everything from ...

    • Item Types in Koha

      One of the key components of your library's collection will be the Item Type designation. Item types are a way for your patrons to identify what the item is and more importantly to Koha how this item circulates in your library. Here is a link to the ...

    • Unique Gentle Nudge Plugin for Koha

      This plugin automates the process of sending patrons to the Unique Management Services (UMS) collections service and updating those patrons in Koha. Gentle Nudge is a product offered by UMS to assist libraries with the recovery of overdue material ...

    • Overdrive Integration with Koha

      An OverDrive integration with Koha will give patrons the ability to search for OverDrive records, place items on hold and checkout them out in your Koha catalog. Tutorial Video: <br> OverDrive Set-Up There are some key pieces of information ...

    • Paypal Plugin for Koha

      PayPal Setup The steps below will walk you through setting up the PayPal business account. PayPal Business Account Set-Up: Log into your PayPal business account. Go to the Tools dropdown menu and select 'All Tools'. Choose Integrate API on the left ...