How Shibboleth Works: Basic Concepts

How Shibboleth Works: Basic Concepts

At its core Shibboleth works the same as every other web-based Single Sign-on (SSO) system. What distinguishes Shibboleth from other products in this field is its adherence to standards and its ability to provide SSO support to services outside of a user’s organization while still protecting their privacy.

The main elements of a web-based SSO system are:

  • Web Browser – represents the user within the SSO process
  • Resource – contains restricted access content that the user wants
  • Identity Provider (IdP) – authenticates the user
  • Service Provider (SP) – performs the SSO process for the resource


Single Sign-on Steps

Step 1: User accesses the Resource

The user starts by attempting to access the protected resource. The resource monitor determines if the user has an active session and, discovering that they do not, directs them to the service provider in order to start the SSO process.

Step 2: Service Provider issues Authentication Request

The user arrives at the Service Provider which prepares an authentication request and sends it and the user to the Identity Provider. The Service Provider software is generally installed on the same server as the resource.

Step 3: User Authenticated at Identity Provider

When the user arrives at the Identity Provider it checks to see if the user has an existing session. If they do, they proceed to the next step. If not, the Identity Provider authenticates them (e.g. by prompting for, and checking, a username and password) and the user proceeds to the next step.

Step 4: Identity Provider issues Authentication Response

After identifying the user, the Identity Provider prepares an authentication response and sends it and the user back to the Service Provider.

Step 5: Service Provider checks Authentication Response

When the user arrives with the response from the Identity Provider, the Service Provider will validate the response, create a session for the user, and make some information retrieved from the response (e.g. the user’s identifier) available to the protected resource. After this, the user is sent to the resource.

Step 6: Resource returns Content

As in Step 1, the user is now trying again to access the protected resource, but this time the user has a session and the resource knows who they are. With this information the resource will service the user’s request and send back the requested data.

Federated Single Sign-on

If you have heard about Shibboleth you have probably also heard something about “federations” or “Federated Single Sign-on”. The steps above are common to all SSO systems, but some of these systems are designed to only work when the Identity Provider and Service Provider are in the same organization, whilst others are designed to work regardless of whether the two components are in the same organization. Implementations that fall into the later category are said to implement Federated Single Sign-on.

It is not uncommon that a given Service Provider may wish to work with more than one Identity Provider (e.g. commercial services with multiple customers, resources used by researchers at multiple organizations), and likewise a given Identity Provider might wish to work with multiple Service Providers. When a group of Identity and Service Providers agree to work together, this group is called a federation.


Next – Identity Provider Discovery, User Attributes and Metadata