Access: Shibboleth Glossary

These are some of the important concepts and terminology used when talking about SAML or Shibboleth. The official Shib wiki has a section on general concepts that may also be useful.

In This Article:

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.

Assertion

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 192.0.2.1") 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.

Attribute

A piece of data about a user, such as their name, email address, job title, home address, phone number, etc. Shib can include attributes in the response to a Service Provider as part of the authentication process.

Attribute Filter Policy

Also referred to as an Attribute Release Policy, this is the mechanism in the Identity Provider that controls which Service Providers can see which attributes. For non-public attributes, a Real Time Directory access request form is required to get signoff from the appropriate data custodians.

Discovery Service (DS)

Allows a user to choose which one of a number of Identity Providers they would like to use. - Most useful in federated contexts, where a Service Provider allows users from a number of different sites. An example of a generally available DS is seamlessaccess.org, which is supported by several large academic publishing companies who have contracts with libraries.

Endpoint

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 Sign-on 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. urn:mace:incommon:umn.edu) or a URL (e.g. https://idp2.shib.umn.edu/idp/shibboleth). This is how Identity Providers and Service Providers refer to each other. It is required to be globally unique; the URL format provides an easy way to accomplish this. Some service providers refer to this as an "Issuer", which reflects where the entity ID appears in a SAML response.

Identity Provider (IdP)

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

Issuer

The Identity Provider or Service Provider's entity ID that created a particular SAML authentication request or response. Some service providers inaccurately use this to refer to an Entity ID.

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.

Metadata

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.

Metadata UI extensions (MDUI)

An optional section of metadata that describes an Identity Provider or Service Provider intended for end user consumption. For example, a Service Provider could include an application name and logo that an Identity Provider could display on its login page. Or an Identity Provider could provide an institution name and logo for a Service Provider to display in a list of possible IdPs as part of a Discovery Service.

Profile

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. More generally, it refers to the "other side" of a SAML interaction (SP from the IdP's point of view, and IdP from the SP's point of view).

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; Shibbolethsupports the SAML Web Single Sign-on profile.

Session

In the context of Shibboleth, 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; this enables single sign-on between multiple service providers. The SP creates its own session information from the IdP assertions, and makes much of this information available to the application via server variables or HTTP headers. 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. Some applications rely on the SP session to maintain a user's "logged-in" status; others just use the SP session at the start to "bootstrap" an application session, and ignore the SP session in favor of its own session handling.

SessionInitiator

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.

Shibboleth

An open-source software project originating from Internet2 that has produced implementations of both a SAML Identity Provider and Service Provider. It is now funded by a consortium of members largely from higher education.

Last modified

Changed

TDX ID

TDX ID
5974