Shibboleth Overview
Shibboleth is a standards-based, open-source single sign-on (SSO) solution that enables people from multiple institutions to access network services shared in a circle of trust known as a federation.
Shibboleth is an implementation of Security Assertion Markup Language (SAML). SAML gives Shibboleth interoperable SSO capabilities. Using SAML also means individual users in the federation need fewer passwords. And SAML provides better auditability features than traditional SSO solutions.
Trust among federations is also established via the secure distribution and synchronization of SAML metadata, the information about the federation's Identity Providers (IdPs) and Service Providers (SPs). This metadata is used to scale trust relationships, facilitate SAML transactions to improve authentication,help apps make authorization decisions, and provide accountability and security.
Each entity's metadata is keyed by its unique name, called an EntityID. Service providers specify what user and/or organizational attributes are required to access their services. And user privacy is protected at all times.
For an overview of the sequence of events during Shib authentication see: Understanding Shibboleth: How It All Fits Together from the official Shib wiki.
The Swiss federation SWITCH has put together a live demonstration of the Shibboleth flows at three levels of detail: "easy", "medium" and "expert". You can start with the easy explanation and drill down if desired.
Simple Bilateral Setup
This type of configuration consists of a single Shibboleth identity provider and service provider that recognize each other and interoperate successfully with each other.
- A user visits a web site that requires authentication.
- The Service Provider (SP) running on the site intercepts the request and determines that the user does not have a session yet.
- The SP redirects to the Identity Provider (IdP) with a parameter encoding a SAML Authentication Request.
- The IdP authenticates the user (by asking for a password, sending the user to another login service, or whatever other method it chooses).
- The IdP sends a form to the browser with a SAML Authentication Response as one of the form fields, with a form target of the SP's AssertionConsumerService. Javascript in the page causes the form to be POSTed immediately without user interaction. If the user has disabled Javascript, they are prompted to submit the form manually to continue.
- The SP's AssertionConsumerService valiates the digital signature on the response, and creates a session for the user populated with the attributes sent from the IdP.
- The SP redirects the user back to the page they had originally requested.
- Now that the user has a session, the SP allows the request to proceed.
Federated Setup
A federated configuration consists of multiple SPs that recognize and interact with multiple IdPs.
- A user visits a web site that requires authentication.
- The SP running on the site intercepts the request and determines that the user does not have a session yet.
- The SP redirects the user to a Discovery Service (DS), which asks the user which IdP they would like to access (e.g. by displaying a list of institutions to choose from).
- The user chooses an IdP, and the DS redirects the user back to the SP with the IdP choice as a parameter.
- The SP redirects to the chosen IdP with the SAML request as a parameter, and the process continues the same as the bilateral setup from here on.
More general information about Shibboleth and SAML