Shibboleth is an Identity Provider that helps facilitate Single-Sign-On (SSO) across multiple organisations. In the context of an MLS library system, a Shibboleth solution allows users to log in to the library system using a single set of credentials.
Throughout this section the topics use the following abbreviations and terms. It is recommended to visit the Shibboleth.net website and familiarise yourself with these terms before continuing with this topic.
SSO - Single-Sign-On
SP - Service Provider
Idp - Identity Provider
Authentication Provider
Library System Integration
Traditionally, in the context of a library system that is hosted separately to the users belonging Active Directory, for example, when using a hosted library system provided by MLS, it is not possible for a user to log in using their domain credentials because the external SP (the library system) cannot authenticate the user against the internal authorisation service, the SP has no awareness of the location of this service and most definitely would not have access to it.
At a basic level when no Identity Provider is in place, consider the following illustration.
1.Firstly, the user sends domain credentials attempting to access a service, to the SP (the library application).
2.At step 2, the application is unable to authenticate the user with their provide domain credentials, so application looks to the Shibboleth configuration.
3.In this example there is no configuration, therefore the SP has no way of authorising the request with an authentication service as the application is not aware where this (or an Identity Provider) resides. The user is denied access to the service.
With a Shibboleth implementation, the SP is able to pass the request to a third party in order to authenticate the user. See the diagram and description below.
The following steps briefly describe the login process.
1.A user accesses the service. The service requires authorisation so the user sends their credentials to the SP.
2.The SP determines whether they have already logged in. If not, the Shibboleth configuration is checked.
3.The SP securely sends the authentication request to the Idp as per the Shibboleth configuration.
4.The Idp authenticates the user against existing authentication services (e.g. Directory Services).
5.The relevant user data is collected from the authentication service and passed back to the Idp.
6.This data is then securely transmitted to the SP.
7.The Service Provider decodes the data and identifies the user in the local database from the provided data (i.e. from the SSID, Logon Name, Barcode, Management ID).
8.If the borrower is located in the library application, they are logged in.
The above demonstrates the basic principle that a Shibboleth implementation provides, there is extensive information on the internet and their website including documentation and installation, see the Shibboleth website here.
When an Idp has been set up and configured, the settings for the Idp can be specified in the application. Click here for instructions on defining these settings.
Copyright © 2013 MLS