Shibboleth (Internet2)

From Wikipedia, the free encyclopedia
For other uses, see Shibboleth (disambiguation).
Shibboleth logo

Shibboleth is a 'single-sign in', or logging-in system for computer networks and the Internet. It allows people to sign in, using just one 'identity', to various systems run by 'federations' of different organizations or institutions. The federations are often universities or public service organizations.

The Shibboleth Internet2 middleware initiative created an architecture and open-source implementation for identity management and federated identity-based authentication and authorization (or access control) infrastructure based on Security Assertion Markup Language (SAML). Federated identity allows the sharing of information about users from one security domain to the other organizations in a federation. This allows for cross-domain single sign-on and removes the need for content providers to maintain user names and passwords. Identity providers (IdPs) supply user information, while service providers (SPs) consume this information and give access to secure content.

History

The Shibboleth project was started in 2000 under the MACE working group to address problems in sharing resources between organizations with often wildly different authentication and authorization infrastructures. Architectural work was performed for over a year prior to any development. After an alpha, two betas, and two point releases were distributed to testing communities, Shibboleth 1.0 was released on July 1, 2003.[1] Shibboleth 1.3 was released on August 26, 2005, with several point releases since then. Shibboleth 2.0 was released on March 19, 2008.[2]

Architecture

Shibboleth is a web-based technology that implements the HTTP/POST, artifact, and attribute push profiles of SAML, including both Identity Provider (IdP) and Service Provider (SP) components. Shibboleth 1.3 has its own technical overview,[3] architectural document,[4] and conformance document[5] that build on top of the SAML 1.1 specifications.

Shibboleth 1.3

In the canonical use case:

  1. A user first accesses a resource hosted by a web server (the Service Provider) that has Shibboleth content protection enabled.
  2. The SP crafts a proprietary authentication request that is passed through the browser using URL query parameters to supply the requester's SAML entityID, the assertion consumption location, and optionally the end page to return the user to.
  3. The user is redirected to either their home IdP or a WAYF (Where Are You From) service, where they select their home IdP for further redirection.
  4. The user authenticates to an access control mechanism external to Shibboleth.
  5. Shibboleth generates a SAML 1.1 authentication assertion with a temporary "handle" contained within it. This handle allows the IdP to recognize a request about a particular browser user as corresponding to the principal that authenticated earlier.
  6. The user is POSTed to the assertion consumer service of the SP. The SP consumes the assertion and issues an AttributeQuery to the IdP's attribute service for attributes about that user, which may or may not include the user's identity.
  7. The IdP sends an attribute assertion containing trusted information about the user to the SP.
  8. The SP either makes an access control decision based on the attributes or supplies information to applications to make decisions themselves.

Shibboleth supports a number of variations on this base case, including portal-style flows whereby the IdP mints an unsolicited assertion to be delivered in the initial access to the SP, and lazy session initiation, which allows an application to trigger content protection through a method of its choice as required.

Shibboleth 1.3 and earlier do not provide a built-in authentication mechanism, but any web-based authentication mechanism can be used to supply user data for Shibboleth to use. Common systems for this purpose include CAS or Pubcookie. The authentication/SSO features of the Java container in which the IdP runs (Tomcat, for example) can also be used.

Shibboleth 2.0

Shibboleth 2.0 builds on SAML 2.0 standards. The IdP in Shibboleth 2.0 has to do additional processing in order to support passive and forced authentication requests in SAML 2.0. The SP can request a specific method of authentication from the IdP. Shibboleth 2.0 supports additional encryption capacity and sets a default session life of 30 minutes.

Attributes

Shibboleth's access control is performed by matching attributes supplied by IdPs against rules defined by SPs. An attribute is any atom of information about a user, such as "member of this community", "Alice Smith", or "licensed under contract A". User identity is considered an attribute, and is only passed when explicitly required, which preserves user privacy. Attributes can be written in Java or pulled from directories and databases. Standard X.520 attributes are most commonly used, but new attributes can be arbitrarily defined as long as they are understood and interpreted similarly by the IdP and SP in a transaction.

Trust

Trust between domains is implemented using public key cryptography (often simply SSL server certificates) and metadata that describes providers. The use of information passed is controlled through agreements. Federations are often used to simplify these relationships by aggregating large numbers of providers that agree to use common rules and contracts.

Development

Shibboleth is open-source and provided under the Apache 2 license. Many extensions such as ShARPE (old), Autograph and GridShib have been contributed by other groups.

Adoption

Federations have been formed in many countries around the world to build trust structures for the exchange of information using SAML and Shibboleth software. Many major content providers support Shibboleth-based access.

In February 2006 the Joint Information Systems Committee (JISC) of the Higher Education Funding Councils of England, Scotland, Wales and Northern ireland announced that they would move from the Athens authentication system to an access-management system based on Shibboleth technology.[6] Since then they updated their position and are endorsing a federated access management solution rather than Shibboleth itself.[citation needed]

References

  1. ↑ Pollack, Michelle (2003-07-01). "I2-News: Internet2 Releases Privacy-Preserving Web Authorizing Software". https://mail.internet2.edu/wws/arc/i2-news/2003-07/msg00000.html. Retrieved 2007-11-28.
  2. ↑ "Shibboleth 2.0 Available". 
  3. ↑ Scarvo, Tom; Cantor, Scott; Dors, Nathan (2005-06-08). "Shibboleth Architecture: Technical Overview". Retrieved 2007-11-28. 
  4. ↑ "Shibboleth Architecture: Protocols and Profiles". 2005-09-10. Retrieved 2007-11-28. 
  5. ↑ Cantor, Scott; Morgan, RL "Bob"; Scarvo, Tom (2005-09-10). "Shibboleth Architecture: Conformance Requirements". Retrieved 2007-11-28. 
  6. ↑ "JISC announces the development of a new access-management system for the UK". Joint Information Systems Committee. Retrieved 2006-07-19. 

External links

Federations

This article is issued from Wikipedia. The text is available under the Creative Commons Attribution/Share Alike; additional terms may apply for the media files.