A brief introduction to Shibboleth: Difference between revisions

From RavenWiki
Jump to navigationJump to search
m (A Management introduction to Shibboleth moved to A brief introduction to Shibboleth)
(Explain that attributes are 'information'; link to lookup)
 
(6 intermediate revisions by the same user not shown)
Line 2: Line 2:
is a set of policies and protocols
is a set of policies and protocols
designed "to support inter-institutional sharing of web resources
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 the US. In
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
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''],
web-based resources similar to that currently provided by [http://www.cam.ac.uk/cs/raven/ ''Raven''],
Line 15: Line 15:
Computing Service as part of Raven. Having selected the University's
Computing Service as part of Raven. Having selected the University's
IdP, the user sees a standard Raven login screen and on completing the
IdP, the user sees a standard Raven login screen and on completing the
login process sees the resource they wanted providing they are
login process sees the resource they wanted, providing that they are
authorised to access it. Access to further resources, even if provided
authorised to access it. Access to further resources, even if provided
by different organisations, uses information already gathered and the
by different organisations, uses information already gathered and the
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
need to include a user's real-world identity. For example,  
include a user's real-world identity. For example,  
some resources is available to any current member of the
it is common for some resources to be available to any member of an organisation, in which case it
University. Using only an attribute that asserts this relationship
may only be necessary to release an attribute asserting this relationship. This
helps to preserve the user's privacy, and reduces the Data Protection
helps to preserve the user's privacy, simplifies processing by the protected
issues surrounding the operation of IdPs and protected
service, and reduces the data protection
services. Shibboleth also supports release of non-anonymous attributes
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
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
Line 45: Line 46:
An initial application for Shibboleth in the UK will be control of
An initial application for Shibboleth in the UK will be control of
access to on-line journals and databases. Access to many such
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'']. The current funding for
resources is currently managed by [http://www.lib.cam.ac.uk/electronicresources/Access_Passwords.htm#Athens ''Athens''] but central funding for
this by [http://www.jisc.ac.uk/ JISC] ceases in July 2008 after which the service will
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
operate on a subscription basis. It is JISC's intention that current
Athens use should transition to Shibboleth. In the short term, JISC
Athens use should transition to Shibboleth. In the short term, JISC
Line 53: Line 54:


Beyond this initial use, groups such as the e-science community are
Beyond this initial use, groups such as the e-science community are
actively investigating using Shibboleth in their particular areas. It
actively investigating use of Shibboleth. It
is already being adopted for various purposes in the US, Europe and
is being adopted for various purposes in the US, Europe and
Australia. Shibboleth is being developed in an open collaborative
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
fashion and is itself based on open standards such as [http://www.oasis-open.org/committees/security/ ''SAML'']. A
Line 62: Line 63:
within the University in parallel with the current Raven service.
within the University in parallel with the current Raven service.


Shibboleth deployments require agreements on technical and policy
Shibboleth deployments require agreement on technical and policy
issues. This can be established by bilateral agreements between IdPs
issues. These can be established by bilateral agreements between IdPs
and corresponding ''Service Providers'' (''SPs''). However this scales
and corresponding ''Service Providers'' (''SPs''), but this scales
badly and it is usual to establish ''federations'' of IdPs and SPs who
badly. A common way to address this is to establish ''federations'' of IdPs and SPs who
mutually agree technical and policy standards to allow their members
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
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
function in the UK. The University joined the federation in January
2007. The UK Federation recommends that the four core attributes
2007. The UK Federation supports use of the four core attributes
listed above should be used between members, and that wherever
listed above between members, and recommnds that wherever
possible only eduPersonScopedAffiliation and eduPersonTargetedID
possible only release of eduPersonScopedAffiliation and eduPersonTargetedID
should be required. It is likely that a less formal 'University of
should be required. It is likely that a less formal 'University of
Cambridge' federation will eventually be needed to support Shibboleth
Cambridge' federation will eventually be needed to support Shibboleth
deployments contained entirely within the University.
deployments contained entirely within the University.

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.