Shibboleth is a software project of the Internet2 Middleware Initiative for providing federated authentication and access control. The Shibboleth System is a standards based, open source software package for web single sign-on across or within organizational boundaries. It allows applications to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.
Shibboleth exists as a layer between an organization's authentication service and another organization's application service. Shibboleth facilitates the communication of authentication and attribute information between the two parties in a protected fashion. This allows users from one organization to utilize applications and resources from another.
More information can be found at: http://shibboleth.internet2.edu/
Shibboleth relies on two organizations trusting each other and providing each other with the data that they require. Before any Shibbolized transaction takes place, the two organizations must communicate technical information about themselves such as URLs, certificates and protocols with which to communicate. In addition to the technical data, business rules must be applied in order to correctly identify the user and fulfill the application's needs such as releasing the user's ID, name or e-mail address or whether to suppress that info.
Much of this coordination takes place through federations. Federations are groups of organizations who agree to exchange data in a certain manner and with a certain regularity. Federations also can designate common attributes which are available to their members. These advanced decisions and implementations can greatly simply the up-front configuration when a new service provider or identity provider wishes to communicate with federation members.
The first step in working with Shibboleth is to learn about the major service components:
SP: Service Provider - the Shibboleth designation for the organization who provides applications or resources in the transaction.
IdP: Identity Provider - the Shibboleth designation for the organization who provides authentication and user attributes in the transaction.
DS: Discovery Service - a web site which lists multiple IdPs and asks the user to select the IdP of their home institution (e.g. UCSB) so they are directed to the proper login page. This was formerly known as a WAYF (Where are you From) Service.
Once configured, a sign-in transaction follows this basic flow:
- A user requests access to an application from an SP
- The user is redirected to a DS where they select their home IdP
- The user is redirected to their IdP where they log in using campus credentials (UCSBnetID and password)
- The user is redirected to the SP where they provide their login session token (automatically)
- The SP checks with the IdP to confirm the credentials supplied
- The SP then requests the predetermined attributes from the IdP in order to facilitate the user's session
- The user's session on the application begins
By virtue of the Shibboleth sign-in process as described above, single sign-on (SSO) is provided as a benefit (or consequence) of the technology. Once you've signed into the IdP, any subsequent SP you visit within the (default 30 minute) timeout will use your existing Shibboleth login session to create a local session.
Unlike many other web applications and/or SSO platforms, Shibboleth does not provide any type of "log out" feature. Because of the distributed nature of the technology there's no reliable way to do this. The only way to ensure that a user's Shibboleth session has been terminated is for the user to close all browser tabs and windows and quit the browser.
The concept (often called Single Log Out, or SLO) is that by clicking a "log out" button in one of several SPs the userlogs out of all SPs served by that same IdP. The current consensus by Shibboleth technologists is that implementing SLO is not advised. Furthermore, implementing a "log out" button in a single Shibboleth SP can create a false sense of security, because of the numerous ways in which a user's Shibboleth session may not in fact be destroyed by the SP log out process.
The bottom line is that even if we could implement some type of "log out" functionality either for a single SP or as an IdP-based SLO system there's no way to guarantee that logout would be completely successful. This is primarily because of the numerous complexities of a distributed SSO, particularly in the case of a user logged into multiple federated services inside and outside of UCSB.