Shibboleth

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

Warning

Shibboleth authentication is considered a legacy protocol and should not be used for new production systems & services. To improve security and streamline access management, we are deprecating legacy single sign-on (SSO) protocols CAS and Shibboleth and will only allow SAML or OpenID Connect (OIDC) via Microsoft Entra ID going forward. SAML and OIDC are modern, standards-based protocols that provide enhanced authentication, authorization, and federation capabilities compared to older protocols like CAS and Shibboleth. By consolidating on SAML and OIDC via Microsoft Entra ID, we will be able to leverage improved security features, reduce complexity, and gain greater visibility into access and usage through unified logging and reporting. Exceptions will be made on a case-by-case basis where there is a compelling business need to maintain legacy protocol support, but the long-term goal is to fully transition to SAML and OIDC via Entra ID for all SSO integration. This change will improve our security posture while also streamlining access management as part of our continued efforts to mature our identity and access management practices.