This wiki space contains a number of topics about Shibboleth as a technical system, but most of the information is really more about SAML, which is the primary (though not only) protocol supported by the IdP and the only one supported by the SP. Understanding Shibboleth is first and foremost a matter of understanding SAML, and secondarily understanding SSO in general and the specific technologies we use to build and support the software.

There have historically not been a large number of books on SAML and even fewer of any quality or real accuracy. One we know of (not free) is SAML 2.0: Designing Secure Identity Federation by Stefan Rasmusson, who has older books on OpenSAML itself, so is familiar with some of the Shibboleth code.

The Shibboleth software is a web-based single sign-on system made up of three components:

  • The Identity Provider (IdP) is responsible for user authentication and providing user information to the Service Provider (SP). It is located at the home organization, which is the organization which maintains the user's account.

  • The Service Provider (SP) is responsible for protecting an online resource and consuming information from the Identity Provider (IdP). It is located at the resource organization.

  • The Discovery Service (DS) helps the Service Provider (SP) discover the user's Identity Provider (IdP). It may be located anywhere on the web and is not required in all cases.

Component Interactions

Basic Interaction

The following diagram shows the interaction between the user, located at their web browser, the IdP, located at the home organization, and the SP, located at the resource organization.

  1. The SP detects the user attempting to access restricted content within the resource.

  2. The SP generates an authentication request, then sends that request, and the user, to the user's IdP.

  3. The IdP authenticates the user, then sends the authentication response, and the user, back to the SP.

  4. The SP verifies the IdP's response and sends the request through to the resource which returns the originally requested content.

Further Details

Given this very basic familiarity with the Shibboleth components and their interactions, the following documentation provides further detail. The section Understanding the Basics provides further information about the concepts and components within Shibboleth. The Identity Provider and Service Provider sections give further details relating specifically to their respective components.

Understanding the Basics

Goals & Requirements

Describes the goals of the Shibboleth software and the environments in which it operates.

System Flow

Describes the general flow through the system.


Describes what metadata is and how it is used by Shibboleth.


Discusses what a user session is and a Shibboleth session differs from normal web application sessions.

Name Identifiers

Describes what Name Identifiers are and how they are used.


A glossary of terms used throughout this wiki.

More Concepts

Entity Naming

Naming guidelines for systems

Attribute Naming

Naming guidelines for attributes

Trust & Credentials

Describes how one Shibboleth component identifiers itself to, and trusts, another.

IdP Discovery

Describes how a service provider determines a user's identity provider.

Advanced Uses

Discussion of more advanced use cases.

Protocols & Profiles

Describes the different request/response types that Shibboleth supports.

Identity Provider

Relying Parties

Describes how the IdP identifies and interacts with relying parties.


Describes how the IdP establishes and maintains sessions.


Describes how the IdP uses metadata.

Attribute Storage

Discussion of attribute storage and access.

Requisite Skills

Describes the skill set an IdP deployer should have.

Service Provider


Describes how the SP establishes and maintains sessions.


Describes how the SP uses metadata.

Attribute-based Access Control

Discusses how information form the IdP can be used to control access to a resource.

Requisite Skills

Describes the skill set an SP deployer should have.