ID Management Discussion #3: Shibboleth Single Sign-On

JoshD · February 7, 2020, 3:06pm

Shibboleth - What is it?

In part 3 of our look at Identity Access and Management options for Cyber Infrastructure large facilities we will be discussing the Shibboleth consortium and how it can be integrated into a federated identity solution.

Shibboleth

Shibboleth is a single sign on provider and a set of standards based, open source identity federation software packages for web single sign on across or within organizational boundries. Shibboleth is part of the InCommon Trusted Access Platform at Internet2, which provides a full suite of software for Identity and Access Management for easy installation and configuration. While Shibboleth was initially started by Internet2, today it is owned and managed by the Shibboleth Consortium. Shibboleth is open source software and licensed and released under the Apache Software License. More Information.

How it works

Shibboleth software consists of 3 parts:

The Identity Provider (IdP) is responsible for user authentication and providing user inforamation to the (2) Service Provider (SP). The IdP is hosted at the home organization, which is the org that maintains the user’s account.
The Service Provider (SP) is responsible for protecting an online resource and consuming the identity information from the IdP. The Service Provider is located at the resource organization.
The Discovery Service (DS) helps the SP discover the user identity from the IdP. It may be located on the web and is not always required.

The purpose of the software is to allow an organization to use their existing authentication mechanism (AuthN) to access web based resources, even if the resource is not operated by that organization. This reduces the number of credentials a user needs to manage, and allows the resource provider to divest the responsibility of storing and maintaining user credentials. Additionally, this allows the user’s identity metadata to be kept and updated by their home organization and that information can be based to the resource provider without the resource provider having to store information about the user. Finally, this allows the user and their organization to control what information is provided about their identity, while the resource providers can request only what is needed to access a particular resource.

Workflow

For a full walkthrough of the Shibboleth SSO workflow with configuration examples, visit the community wiki.

Metadata

One of the advantages of using a Single Sign-On provider like Shibboleth is it alleviates the need for the multiple sites to maintain and store user data. Shibboleth accomplishes this by having the home institution Identity Provider store and maintain metadata for the users’ identity.

Shibboleth Identity Providers use SAML identity tokens which are able to store configuration data in XML form. Shibboleth metadata is stored in the SAML config usign the SAML 2.0 specifications standardized by OASIS. In addition to SAML 2.0, they also support using “profiles” with other identity protocols like SAML 1.x and WS-Federation. Shibboleth also includes some extensions to the SAML core metadata scheme, which can be seen here.

The topic of XML metadata is outside the scope of this point, but the main takeaway for Shibboleth is the idea that the SAML identity that is passed from the IdP to the SP can contain some number of roles and attribues that the service provider can then use to provide access to a resource using their own RBAC or ABAC scheme.

Sessions

Sessions in Shibboleth are persisted through the use of first party cookies. Shibboleth is developed and maintained for most major browser’s current release, and at the time of writing does not require or utilize any third party cookies to maintain sessions. In any given Single Sign-On interaction, several sessions may be active at one time.

Sessions at the IdP are used to provide SSO, caching identity information to remove the need for additional AuthN
Discovery Service sessions help to automate the IdP selection, to reduce the need for additional user interaction.
Service Provider sessions persist the SSO login across individual HTTP requests from a single client and can be broad or narrow, defined to a host or individual applications.
Each application can (and usually will) maintain its own session within the browser.

Be Aware: These sessions are largely independent of each other and any type can exist with or without any of the others. The expiration of one session does not effect the other sessions. This means that special care must be taken when configuring Shibboleth so that log out terminates all required sessions at once.