A brief introduction to Shibboleth: Difference between revisions

From RavenWiki
Jump to navigationJump to search
mNo edit summary
(Explain that attributes are 'information'; link to lookup)
 
Line 21: Line 21:


Shibboleth-protected resources make access control decisions based on
Shibboleth-protected resources make access control decisions based on
attributes supplied by the user's IdP. These attributes may or may not
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,  
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  
it is common for some resources to be available to any member of an organisation, in which case it  
Line 30: Line 30:
services and IdPs. Shibboleth also supports release of non-anonymous attributes
services and IdPs. Shibboleth also supports release of non-anonymous attributes
where required. For University users, attribute values will be derived
where required. For University users, attribute values will be derived
from information in lookup.
from information in [http://www.lookup.cam.ac.uk/ lookup].


Four core attributes form the 'base set' for inter-organisation
Four core attributes form the 'base set' for inter-organisation

Latest revision as of 08:50, 26 April 2007

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 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 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 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.