Shibboleth Glossary

These are some of the important concepts and terminology used when talking about SAML or Shibboleth.

Application ID

In the Shibboleth SP, this is a way to implement different settings for different parts of your URL space, such as having a different entity ID for a particular directory. Most installations will only use the “default” application ID.


An XML document that contains claims made by an Identity Provider about a user. A typical SAML version 2 authentication response contains an authentication assertion with information about the act of authentication itself (e.g. "this user authenticated with Duo at 10:52am today from IP address") and an attribute assertion containing information about the user ("this user is Chris from Identity Management").

Assertion Consumer Service (ACS)

An endpoint (URL) on a Service Provider to which the user's browser will send authentication responses. A response contains assertions about the user and how they authenticated, and this is the service that "consumes" the assertions to turn them into a Service Provider session. The Service Provider's metadata lists its ACS URLs; this is how the Identity Provider knows which ACS URLs are OK  to send to the browser to.

Discovery Service (DS)

Allows a user to choose which one of a number of Identity Providers they would like to use. Formerly known as the “Where Are You From” (WAYF) service. Most useful in federated contexts, where a Service Provider allows users from a number of different sites.


A URL on an Identity or Service Provider that performs a specific function within the SAML authentication protocol. The two most commonly used endpoints are the Identity Provider's Single Signon Service and the Service Provider's Assertion Consumer Service.

Entity ID

The “name” of an identity provider or service provider. It is a URI, which can be either a URN (e.g. or a URL (e.g. This is how Identity Providers and Service Providers refer to each other.

Identity Provider (IdP)

Authenticates users and generates assertions about them for use by Service Providers.

Lazy Sessions

A technique to allow access to a site despite the user not having authenticated yet.  Activated by setting “requireSession 0” in the RequestMap or .htaccess on the SP.  This is typically used in combination with an explicit “login” button on the page that triggers authentication (e.g. by redirecting the user to a SessionInitiator like /Shibboleth.sso/Login).  A typical use case would be a wiki, which allows public read access, but requires authentication to update.


An XML document describing an Identity Provider or Service Provider. It contains the entity ID, public signing and/or encryption keys, endpoints, administrative contact information, and other data useful for carrying out SAML operations. An Identity Provider creates a metadata file and gives it to all of the Service Providers that will be using it. A Service Provider likewise creates a metadata file and gives it to the Identity Providers it uses. The Shibboleth SP software has an endpoint that will automatically generate basic Service Provider metadata for you, which you can complete by adding contact information and any additional endpoints needed. Federations often take on the role of mediating the publishing of metadata among its participants.


A set of additional specifications around the SAML protocol that tailor its use for a specific function. We support the SAML Web Single Sign-on profile, which defines how SAML can be used to implement web authentication.

Relying Party (RP)

Another name for Service Provider. This term was used by one of the protocols which was merged into the final SAML version 2 specification.

Service Provider (SP)

Accepts assertions about users from Identity Providers and uses them for access control and/or personalization in applications.

Security Assertion Markup Language (SAML)

A technical standard issued by the OASIS organization defining a means of communicating authentication-related information between administratively disparate systems. There are several profiles of the SAML protocol to promote interoperability for specific functions; we support the SAML Web Single Sign-on profile.


Sessions are stored at three levels. The IdP maintains a session that records how and when the user authenticated with the IdP, and when the session expires, among other attributes. The SP creates its own session information from the IdP assertions, which is available to the application. Each application that lies behind a SP may manage sessions in their own way, with their own settings that describe when a session should expire, and other attributes specific to that application.


An endpoint (URL) on the Service Provider that initiates the SAML protocol to authenticate a user. This is specific to the Shibboleth Service Provider implementation; it is not part of the SAML standard. A Service Provider can initiate authentication (for example, in response to the user clicking a "Login" button on the Service Provider's web site) by redirecting the user to one of its SessionInitiators. The default configuration has one located at /Shibboleth.sso/Login. While a Service Provider may have more than one SessionInitiator with different configurations (most commonly, configured to use different Identity Providers), most applications will only need to use one. If you use the RequestMap or Apache .htaccess/httpd.conf configuration to require sessions for parts of your site, the Shibboleth SP will take care of the SessionInitiator redirect so you do not need to code for it explicitly.