Shibboleth is a "project of the Internet2 Middleware Initiative". 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:

1. A user requests access to an application from an SP
2. The user is redirected to a DS where they select their home IdP
3. The user is redirected to their IdP where they log in using campus credentials (UCSBnetID and password)
4. The user is redirected to the SP where they provide their login session token (automatically)
5. The SP checks with the IdP to confirm the credentials supplied
6. The SP then requests the predetermined attributes from the IdP in order to facilitate the user's session
7. 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.

The notion of a log out feature in a Shibboleth single sign on (SSO) services is one that is often misunderstood to be feasible. The concept (often called Single Log Out, or SLO) is that by clicking a link in one of several SPs, the user logs out of all SPs served by that same IDP. After a great deal of thought by a great number of highly intelligent and informed people throughout the world, the current consensus is that implementing what's known as SLO in Shibboleth is not advised. Furthermore, implementing a 'log out' button in a Shibboleth-protected application 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 Shibboleth log out process. Instead of rehashing an involved discussion on the matter, I'll refer interested commentators and kibitzers to Scott Cantor's article on Why Shibboleth does not support SLO.

The bottom line is that while implementing the logout functionality available in UCSB's Shibboleth infrastructure may successfully log a user out of their Shibboleth sessions on the IDP and the SP, it is not guaranteed 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. 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.