View source for A brief introduction to Shibboleth

Strictly speaking, [http://shibboleth.internet2.edu/ ''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 [http://www.internet2.edu/ Internet2]. In
practice it is a system providing an access control system for
web-based resources similar to that currently provided by [http://www.cam.ac.uk/cs/raven/ ''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 that 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
information supplied by the user's IdP in the form of ''attributes.'' 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 [http://www.lookup.cam.ac.uk/ lookup].

Four core attributes form the 'base set' for inter-organisation
Shibboleth deployments. Their names reflect their original definition
in the [http://www.educause.edu/eduperson ''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 [http://www.lib.cam.ac.uk/electronicresources/Access_Passwords.htm#Athens ''Athens''] but central funding for
this service by [http://www.jisc.ac.uk/ 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 [http://www.oasis-open.org/committees/security/ ''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 [http://www.becta.org.uk/ Becta] have established [http://www.ukfederation.org.uk/ ''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 supports use of the four core attributes
listed above between members, and recommnds that wherever
possible only release of 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.