Overview
Shibboleth is a web-based Single Sign-On infrastructure. It is based on SAML, a standard for the exchange of authentication data. Shibboleth has been adopted by the University of California as the basis for federated Single Sign-On between the UC campuses. Shibboleth allows one to authenticate using a local institutional service (IdP) to gain access to remote resources and services (SPs). Our local UC Berkeley authentication provider is based on CAS backed by CalNetAD and LDAP.
Please see the iNews articles on Federated Identity Management at UC Berkeley for more information.
For general background and detailed documentation directly from the Shibboleth Project, see Understanding Shibboleth.
If you have a service that has a configuration for external SSO / SAML, see "How to setup SSO/SAML with your service."
Terminology
Understanding Shibboleth and SAML is much easier after learning some terminology. A successful deployment of Shibboleth involves two critical software components:
Identity Provider (IdP)
This is the server that handles authentication of users. UC Berkeley has deployed an IdP at shib.berkeley.edu. Only one IdP is needed per campus.
Service Provider (SP)
An IdP is useless without Service Providers. Service Providers are web applications, resources, or other services which require authentication. The Shibboleth SP software allows most web servers (namely Apache and IIS) to integrate with an IdP or a number of IdPs. Examples of SPs are: UCReady, the UCB Learning Center (a SumTotalSystems application hosted at UCOP by SumTotalSystems), and At Your Service (AYSO, hosted at UCOP).
The SP software consists of several components:
- ISAPI Filter - This is only used for IIS deployments. It intercepts requests to IIS and redirects users to an IdP or WAYF. After the user authenticates, it also handles the callback which tells your SP that the user has authenticated. During handling of this callback the ISAPI Filter collects attributes which describe the authenticated user. The filter is configured through shibboleth.xml.
- Apache Module - This is only used for Apache deployments. It is essentially the same as the ISAPI Filter but for the Apache web server. In addition to shibboleth.xml, some configuration is required via httpd.conf.
- Shibd - This is a service (Windows) or daemon (UNIX) which handles attributes request queries from the SP to the IdP. Shibboleth attribute requests are part of the SAML standard and are made via a back channel SOAP call to the IdP (usually on port 8443). In order to receive user attributes, this service must be running.
- Attribute Acceptance Policy - This policy dictates which attributes the SP wants and which IdPs are authorized to provide them. It may also define specific formats that the values must match. In addition, the AAP determines what HTTP headers will be used for mapping attributes that are supplied by the IdPs. There are two files that combine together for this functionality, the attribute-map.xml and attribute-policy.xml.