By Danyon Sewell and Aleisha Amohia, Catalyst Koha developers
Libraries are making it easier for users to log in to Koha by implementing single sign-on (SSO). Single sign-on is a method of external authentication that enables users to log in to multiple applications with one set of credentials. This means users could conveniently and securely go through one login portal to access their intranet, email, and other systems, as well as their Koha library system.
There are different protocols (agreed set of rules) for implementing SSO. This blog post will cover several authentication options that Koha offers to allow users to log in.
The basic method of authentication offered by Koha is local login.
All Koha accounts can have their own username and password defined within Koha. Local login still works even if additionally implementing SSO. This can be useful when there are library users from outside of your organisation, or IT vendors, who need access to Koha and do not have SSO accounts.
However it does mean that users could continue to access Koha using local login credentials even after they leave your organisation and their SSO account is removed, so you should ensure they do not have local login credentials in order to prevent this from occurring.
OAuth 2.0 and OIDC
OpenID Connect (OIDC) is a simple identity layer built on top of the OAuth 2.0 protocol. The OIDC layer verifies the identity of the user, and the OAuth protocol authorises their access to Koha.
Koha 22.11 introduced a feature that makes it easier than ever to implement SSO using the OAuth and OIDC. Library IT departments can configure much of the SSO setup themselves via the Koha staff interface.
Configuration of SSO with OAuth and OIDC can be found in the Koha Administration module of Koha, under ‘Identity providers’. Once configured, the library must ask their Koha vendor to restart services for the changes to take effect.
With this feature, it is now possible to integrate with multiple identity providers simultaneously. This means library IT departments can now easily allow both users within their organisation and users from external vendors to be able to SSO authenticate to Koha. They would simply need to add multiple entries in the 'Identity providers' page for each domain and then ask their Koha vendor to restart services.
When multiple identity providers are configured, these can show as different login portal options for the user to select.
Similarly, multiple email domains can be supplied under a singular identity provider configuration, in case external vendors are included under the same SSO application.
Security Assertion Markup Language (SAML) is a protocol that allows the exchange of authentication data between a Koha provider and identity providers such as Azure AD or Google. Koha has a built-in integration with Shibboleth, which is an SSO system based on SAML.
Shibboleth requires the Koha provider and identity provider to swap metadata. This is the handshake which allows the two parties to establish a ‘trust relationship’.
When Shibboleth is enabled, by default users will see both the option to log in with Shibboleth and the option to log in with local login. Local login can be hidden or bypassed easily using Koha system preferences.
When logging in via Shibboleth, users will be redirected to the login portal for their identity provider. If the login is successful through the portal, Koha will look for a matching user in the database to authenticate to Koha and redirect back to the library.
If user provisioning is configured and a matching user is not found in the Koha database, their account will be automatically created after they authenticate through the portal, and they’ll be successfully logged into Koha.
Lightweight Directory Access Protocol (LDAP) is a protocol that allows vendors to look up information about users or devices within a network. Organisations would set up an LDAP server (or directory) which contains information about their users.
When LDAP is enabled, users would log into Koha using the local login form. Koha then uses their credentials to search for and match a user in the LDAP directory, or the Koha database as a fallback. LDAP also provides the ability to provision new users in Koha or update Koha accounts.
All authentication methods other than local login require vendor support to enable and configure.
If you have any questions or comments about this News item, or would like some support with your Koha instance, you are welcome to email us at [email protected] (New Zealand) or [email protected] (Australia).
Follow Catalyst Koha on Twitter or sign up to our newsletter!