Shibboleth

Links


What is Shibboleth?

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 sites 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.net/

Does Shibboleth replace WebAuth or another organization’s SSO?

Absolutely not. Shibboleth exists as an intermediary between Webauth and a protected application. It allows users to log in to whatever SSO they have available to them (in UCI’s case, Webauth) and utilize resources from a third party using those credentials. Shibboleth continues to rely on an organization’s SSO (again, for UCI it’s Webauth) to actually perform authorization for a user.

How does Shibboleth work?

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.

Federations

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.

Transactions

Once pre-configured, transactions are allowed to occur following this basic flow:

  1. A user requests access to an application from an SP
  2. The user is redirected to a WAYF where they select their home IdP
  3. The user is redirected to their IdP where they log in to their home SSO
  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

Whoa! What are these terms: SP, IdP and WAYF?

An SP is an abbreviation for Service Provider, which is the Shibboleth designation for the organization who provides applications or resources in the transaction.

An IdP is an abbreviation for Identity Provider, which is the Shibboleth designation for the organization who provides authentication and user attributes in the transaction.

WAYF is an abbreviation for the phrase “Where Are You From?” which is a web site which lists multiple IdPs and asks the user to select their IdP so they are directed to the proper SSO.