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 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 include a user's real-world identity. For example, it is common for some resources to be available to any member of an organisation in which case it may only be necessary to release an attribute asserting this relationship. This helps to preserve the user's privacy, simplifies processing by the protected service, and reduces the data protection issues surrounding the operation of protected services and IdPs. 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 but central funding for this service 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 use of Shibboleth. It is 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 agreement on technical and policy issues. These can be established by bilateral agreements between IdPs and corresponding Service Providers (SPs), but this scales badly. A common way to address this is to establish federations of IdPs and SPs who agree technical and policy standards that 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.