This page contains notes about developing, testing and demonstrating Shibboleth and related software.
An initial goal is to describe a minimal Shibboleth development/test/demonstration environment, and to provide instructions for its creation.
Shibboleth (1,2,3) provides a federated authentication service for browser-facing web applications. That is, it allows a web-facing service run by one administrative domain to apply access controls based on user authentication information coming from a different administrative domain.
Shibboleth version 1 does not provide support for providing authentication and related information to programs that run behind the visible web front end, such as non-interactive grid applications, etc. Such capability is intended to be provided by Shibboleth version 2 through the use of features of SAML 2.0. [at the time of writing this, it is not entirely clear to me whether this will be a clariifcation or profile of SAML 2.0, but is likely to be based on Liberty Alliance work, and is currently a work-in-progress]
In addition to providing authentication tokens (e.g. confirming that the service requester is a member of Oxford University), Shibboleth also provides a service to access additional, possibly sensitive, information ("attributes") about the authenticated person or entity (e.g. a research project code to which the requester is permitted to charge services). But such information is made available only to the software component that initiated the original Shibboleth authentication transaction. The authentication transaction depends on certain user interactions that take place using a web browser. Therefore, there is no controlled way for a component that does not have a direct web interface to gain access to Shibboleth user attributes: the best we can do with the current version of Shibboleth is have the web front-end collect the relevant attributes and pass them non-web-facing applications (e.g. per (5)), but this introduces a new set of security concerns:
the web front-end must be trusted to access the attributes that are needed by the back-office (non-web-facing) application. It may be that such attributes should be seen only by the back-office application (e.g. in the case of online credit card processing)
- even if the web front-end is fully trusted, the mechanism used to convey user attributes represents another potential point of attack for compromising their security
- having authenticated with a known front-end, the user is no longer in control of which applications are permitted to access his attributes
Shibboleth 2, through use of features in SAML 2.0, is intended to overcome this limitation by allowing the attribute access to be separated from the authentication transaction. The web front-end conducts the authentication as per Shibboleth 1, and passes authentication information along with a constrained delegation description that allows the back-end system to query Shibboleth for permitted attributes. If the constrained delegation does not allow access to an attribute required by the back-office application, the matter must be referred back to the front-end system, which can then seek the user's permission to disclose the required attribute to the requesting back-office application.
1.1. Single sign-on requirements
In addition to providing attributes to non-web-facing systems, Shibboleth 2 also addresses the related problem of supporting single sign-on.
Much of the work on access control systems for education and research environments aims to provide access to a widely distributed range of resources from a single act of authentication, thereby easing controlled flows of information. Even when the back-end applications are web-facing, being required by Shibboleth 1 to engage in an authentication transaction means that the goal of single sign-on is defeated; effectively, for the purposes of obtaining authentication-related information, single sign-on requires these applications to behave as if they have no web-facing presence.
1.2. Shibboleth and SAML
Shibboleth makes extensive use of SAML. SAML defines a base language for expressing security assertions (e.g. a token indicating that the holder has successfully authenticated with a specified identity provider), protocols for exchanging such assertions, and usage profiles. Usage profiles ensure interoperability of conforming components by specifying assertion vocabularies that may be exchanged and protocols used to perform such exchanges. SAML client profiles used by Shibboleth cover only browser clients (i.e. clients that conduct an authentication transaction by issuing an HTTP request and responding appropriately to the responses received, and are presumed to have a direct user interface with a person who can provide authenticating data).
Many aspects of federated authentication were unspecified in SAML 1 (7,8), which resulted in several incompatible ways of handling federation: proprietary SAML solutions focusing on B2N single sign on, the Liberty alliance with its focus on B2C and privacy concerns, and Shibboleth for educational environments where personal anonymity is a key concern. SAML 2.0 (9) is a revision of SAML 1, which incorporates standard mechanisms for dealing with the federation requirements of the various systems built uppn SAML 1. SAML 2.0 also provides the machinery that is required to perform constrained delegation of authentication tokens, but not necessarily a single well-defined way to achieve this.
1.3. Authenticating non-browser-facing services
Shibboleth 1 is built using SAML 1. Because Shibboleth authentication mechanisms are browser facing (see above), and the hand-off mechanisms are not fully standardized in SAML 1, there is no common mechanism for delegating to a system that does not itself use Shibboleth's browser-facing interfaces.
For Shibboleth 2, work is under way to use SAML 2.0 features to permit assertions to be issued that can be utilized, in a controlled fashion, by entities other that the party to whom they were originally issued. This is currently a work in progress, and details have yet to be finalized.
(4)), but current activity (March 2006) in this area is being based on work of the Liberty Alliance, and is not yet available for public view.]]]
2. Shibboleth environment requirements and installation
http://shibboleth.internet2.edu/ - Shibboleth project
http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-tech-overview-latest.pdf - Shibboleth technical overview
http://shibboleth.internet2.edu/docs/internet2-mace-shibboleth-arch-protocols-latest.pdf - Shibboleth protocol specification
http://www.oasis-open.org/committees/download.php/16076/sstc-saml-constrained-delegation-profile-draft-00.pdf - SAML constrained delegation profile (work-in-progress)
http://www.dsg.port.ac.uk/events/workshops/VRE05/talks/Jasper%20Tredgold.ppt - Personalisation, Shibboleth and WSRP in the SPIE Project, Jasper Tredgold's presentation to the Sakai VRE demonstrator workshop help in Portsmouth, January 2006.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security - OASIS Security Services technical committee (Home of SAML)
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security#samlv10 - SAML 1.0 information
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security#samlv11 - SAML 1.1 information
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security#samlv20 - SAML 2.0 information
3.1. Other links
http://spie.oucs.ox.ac.uk/ - Shibboleth-aware Portals and Information Environments (SPIE) project website
http://www.oucs.ox.ac.uk/rts/spie/ - Shibboleth-aware Portals and Information Environments project (SPIE) project, Oxford site
https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/ShibTwoRoadmap - Shibboleth 2 roadmap
https://mail.internet2.edu/wws/arc/shibboleth-dev - Shibboleth developers mailing list
http://spie.oucs.ox.ac.uk/Wiki.jsp?page=NCeSSExtendedAbstract - overview of requirements for N-tier authentication
http://www.w3.org/2006/03dc-aus-lga/swauth - Notes by Dan Connolly from a web authorization workshop.
https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/WebServices - "n-tier authentication notes from Scott Cantor.
https://authdev.it.ohio-state.edu/twiki/pub/wsf/LAP_IDWSF_2_0_ReviewDraft3-20060413.zip - release candidate Liberty Alliance specs (needs Shibboleth authentication to access) - I think these may contain the technical details for n-tier authentication that Scott Cantor referred to.
http://www.switch.ch/aai/howto/ - SWITCH documents for setting up Shibboleth
-- GrahamKlyne 2006-03-02 13:33:07