There are two major components to a Shibboleth system:

  1. Identity Provider - the software run by a university or other organization with Subjects wishing to access a service
  2. Service Provider - the software run by the provider managing the restricted service

When a Subject attempts to access a service, the Service Provider redirects the Subject to the campus Identity Provider managing the Subject's Credentials. The Subject then authenticates with his or her campus Credential. After a successful authentication, the campus Identity Provider passes back to the Service Provider a minimal set of identity information about the Subject. The Service Provider uses the identity information to determine whether or not the Subject is authorized to access the resource.

At Texas A&M, Shibboleth is used with CAS as a Single-Sign-On service. When Shibboleth must perform an authentication, CAS is called. If the customer has an existing CAS session active, they will not be prompted for their NetID credential. The strengths of the CAS service for NetID and password management are used for all Shibboleth-enabled services.

For more information on how Shibboleth works, the SWITCH Federation site offers a series of technical explanations from easy to expert.

Requesting a Shibboleth Integration


Shibboleth should now generally be avoided when launching new production systems & services. If your system is constrained and requires certain attributes only available via Shibboleth, reach out to for assistance.