A brief introduction to Shibboleth

Strictly speaking, Shibboleth is a set of policies and protocols designed "to support inter-institutional sharing of web resources subject to access controls" (http://shibboleth.internet2.edu/about.html) developed by Internet2 in the US. In practice it is a system providing an access control system for web-based resources similar to that currently provided by Raven, but extended to allow users from multiple organisations to access resources provided by other independent organisations.

This extension make Shibboleth more complex than the current Raven service, but from a user perspective there is little difference. On initially accessing a Shibboleth-protected resource, a user is asked to select a service willing to identify them (an Identity Provider, or IdP). For University users this is a service operated by the Computing Service as part of Raven. Having selected the University's IdP, the user sees a standard Raven login screen and on completing the login process sees the resource they wanted providing they are authorised to access it. Access to further resources, even if provided by different organisations, uses information already gathered and the existing Raven login to streamline the process.

Shibboleth-protected resources make access control decisions based on attributes supplied by the user's IdP. These attributes may or may not need to include a user's real-world identity. For example, some resources is available to any current member of the University. Using only an attribute that asserts this relationship helps to preserve the user's privacy, and reduces the Data Protection issues surrounding the operation of IdPs and protected services. Shibboleth also supports release of non-anonymous attributes where required. For University users, attribute values will be derived from information in lookup.

Four core attributes form the 'base set' for inter-organisation Shibboleth deployments. Their names reflect their original definition in the eduPerson LDAP specification. They are:

• eduPersonScopedAffiliation indicating a user's relationship (e.g., staff, student, etc.) with the organisation running their IdP.

• eduPersonTargetedID providing a persistent user pseudonym that is distinct for each protected service.

• eduPersonPrincipalName providing a persistent user identifier which is consistent across all protected services.

• eduPersonEntitlement allowing an organisation to assert that a user satisfies additional sets of specific conditions.

An initial application for Shibboleth in the UK will be control of access to on-line journals and databases. Access to many such resources is currently managed by Athens. The current funding for this by JISC ceases in July 2008 after which the service will operate on a subscription basis. It is JISC's intention that current Athens use should transition to Shibboleth. In the short term, JISC have sponsored a 'Gateway' that allows resources current protected by Athens to be accessed via Shibboleth.

Beyond this initial use, groups such as the e-science community are actively investigating using Shibboleth in their particular areas. It is already being adopted for various purposes in the US, Europe and Australia. Shibboleth is being developed in an open collaborative fashion and is itself based on open standards such as SAML. A benefit of this open approach is that built-in support for Shibboleth is already appearing in commercial and open source software products. It is likely that we will eventually need to support its use within the University in parallel with the current Raven service.

Shibboleth deployments require agreements on technical and policy issues. This can be established by bilateral agreements between IdPs and corresponding Service Providers (SPs). However this scales badly and it is usual to establish federations of IdPs and SPs who mutually agree technical and policy standards to allow their members to inter-work. JISC and Becta have established The UK Access Management Federation for Education and Research to fulfil this function in the UK. The University joined the federation in January 2007. The UK Federation recommends that the four core attributes listed above should be used between members, and that wherever possible only eduPersonScopedAffiliation and eduPersonTargetedID should be required. It is likely that a less formal 'University of Cambridge' federation will eventually be needed to support Shibboleth deployments contained entirely within the University.