How Shibboleth Works: Identity Provider Discovery, User Attributes and Metadata
Identity Provider Discovery
After reading Basic Concepts, you may have asked how a Service Provider working with multiple Identity Providers knows where to send an authentication request along with the user? The answer is that in truly federated applications the user is asked and that prompt is known as Identity Provider Discovery. In non-federated, “siloed” applications, the URL is often used as a trigger for using a particular Identity Provider, but this approach is inherently broken for a variety of reasons.
Another feature that most services take advantage of when using Shibboleth is the ability to receive data about the user from the Identity Provider. This data known as user attributes can be anything that the Identity Provider knows about the user and that may be helpful to the Service Provider. Some examples of this type of data are:
- User’s email address and name;
- Groups to which the user belongs;
- Information about the user’s role in the organization;
- Specific privileges a user has been granted.
The ability to preserve a user’s privacy is a principal concern within all Shibboleth products. Both the
Identity Provider and Service Provider allow the deployer to set attribute filter policies to address these concerns. Within the Identity provider this policy controls which attributes will be released to which Service Providers, while within the Service Provider this policy controls what information will be accepted from which Identity Providers.
Another question you may have asked is if the SSO process is undertaken via HTTP, how do the Identity provider and Service Provider know which URLs to use when communicating with each other?. This function is accomplished by a metadata document that describes various technical aspects of an Identity Provider or Service Provider.
The metadata for an Identity Provider or Service Provider usually contains the following information:
- a unique identifier, known as an entity id;
- a human-readable name and description;
- a list of URLs to which messages should be delivered and some information about when to use each;
- cryptographic information used when creating and verifying messages.
A common function of a federation is to publish a file containing all the metadata for the Identity Providers
and Service Providers that have agreed to work together, which is then made available to all participants. This way a Service Provider does not need to contact every Identity Provider when it changes its metadata (or vice versa), but simply provides it to the federation.
Next – Profiles and Bindings