Existing Documentation

  1. SWITCH AAI (Authentication & Authorisation Infrastructure) documentation

    The AAI in a nutshell flier succinctly describes why you might want to use Shibboleth, and the System and Interface specification gives a good description of how it works.

    Currently seven universities, covering more than 110,000 users, have integrated their user directories into AAI. Several AAI-resources, primarily in the field of e-learning, are used on a regular basis by more than 10,000 users. For reference there is an AAI Service Agreement, which is ready to be signed. This could act as a model for future federations. Between 3 August and 17 October 2005 a migration of the current AAI infrastructure to a production infrastructure and a separate test infrastructure will take place.

    There are a number of Switch HOWTOs including

    Resources (Shibboleth Service Providers, Targets)

    Home Organizations (Shibboleth Identity Providers, Origins)

    Metadata / Certificates

    There are also other documents including an AAI Service Subscription documents set is for organisations that want to become Federation Members. The main AAI Policy is part of the Service Agreement document set. It defines concepts related to the AAI federation and establishes a firm set of rules that all AAI participants are expected to follow. It also lays the groundwork for the exchange of Attributes between organizations in accordance with the data protection laws.

    Finally in this context, AAI has defined an Authorization Attribute Specification which sets the standard for attributes to be used when exchanging authorization information among organizations within the scope of AAI. The format chosen for attribute definition is close to the LDAP syntax. The corresponding LDAP schema might be of use to AAI Home Organizations implementing this specification.

  2. It is worth referring to the Internet2 Shibboleth Project, especially information at:

    • Overview & requirements (Feb 2001)

      In summary, Shibboleth, a joint project of Internet2/MACE and IBM, is investigating architectures, frameworks, and practical technologies to support inter-institutional sharing and controlled access to web available services. The project will produce an analysis of the architectural issues involved in providing such inter-institutional services, given current campus realities and the current state of relevant standards. It will also produce a pilot implementations to demonstrate the concepts.

      Shibboleth aims to develop an architecture for a standards based vendor independent web access control infrastructure that can operate across institutional boundaries. The Internet community has achieved significant commonality in the web space by virtue of having such standards (e.g. HTML/HTTP/JavaScript/SSL/etc), and having a few no- or low-cost implementations of the clients and servers. Standards and standard architectures have promoted interoperability. The Shibboleth project seeks to define similar standards for the secure exchange of trusted interoperable information which could be used in authorization decisions. The goal is to develop and promulgate an architecture, which can then be used in a multi-vendor, open source, standards based environment. If a commercial product fits in this scenario, it does so because it embodies an architecture that can potentially be replicated in a multi-vendor/open-source/standards-based way.

    • Origin deployment guide (Shibboleth version 1.2)
    • Target deployment guide (Shibboleth version 1.2)

      • Shibboleth Version 1.2 was released on July 2, 2004

    However, developers should look out for new versions of the installations, e.g.:

    Shibboleth Origin Deployment Guide, for Shibboleth Version 1.2.1 was released on November 15, 2004. Shibboleth 1.2.1 was a bug-fix release intended to address stability, major bugs, and small issues that had arisen since the release of 1.2. For a list of new features and fixes, developers should refer to the NEWS.txt file in the doc/ folder of the distribution.

    Most recently a beta test of Shibboleth 1.3 was released.

    Developers should also note the following advice: The default configuration of Shibboleth is not secure and should not be used for protection of production content. The example private key bundled with the distribution is publicly available, widely circulated, and well-known; also, the default federation and trust metadata is for testing purposes only. For information about securing a Shibboleth deployment, please refer to the production guide. Shibboleth should only be used to protect sensitive content when deployed carefully in conjunction with proper trust settings and policies.

    There are some more demos related to the Internet2 Shibboleth project that you might want to look at.

    • Shibboleth Demo at Internet2: There is a Shibboleth protected web resource located at https://wayf.internet2.edu/InQueue/sample.jsp

      You should authenticate as user from the organization Example State University (example.edu) with username demo and password demo.

    • Demo integrating Blackboard with Shibboleth: This description guides you through a demo with a 'shibbolised' Blackboard server.

  3. For further information on Federations and their management in the US, the InQueue Federation guidelines give a summary of the US situation, and

  4. In the UK there is documentation from the LSE based SECURe project especially:

    • A Shibboleth Origin Set Up Guide - for Shibboleth version 1.1 since the project was funded between 2002 and 2004. However, although the versions of Shibboleth have moved on this document still contains valuable information.

    • An Institutional Single Sign On Set Up Guide which describes setting up the Yale Central Authentication System webISO, which is an alternative to PubCookie

      The SECURe project describes the installation of the Yale Central Authentication System. This has a two part architecture, with clients protecting resources and a central server providing the authentication (a design common to such systems). The system, as provided by Yale, needs an authentication connector to be added; the SECURe project has provided a connector for the authbroker system, which is configurable to use a wide range of authentication backends.

    • An Active Directory Compatible Implementation of the eduPerson Schema Extensions

      This document details a procedure for introducing an Active Directory (AD) compatible implementation of the eduPerson schema extensions into an AD based Directory Infrastructure. There are four sections to this document. The first provides some information about the eduPerson class and describes the environment where the deployment took place. The second section compares and contrasts the various implementation possibilities and outlines the changes that need to be made to your domain(s) and forest in order to bring Active Directory to a point where the schema extensions can be introduced. The third section details why the reference eduPerson attribute definitions needed to be changed in order to work with AD and how the resulting implementation differs from the original. The final section details the procedure for injecting the eduPerson class into the AD schema.

    • Shibboleth Target Set Up Guide [forthcoming] - still not there October 2005

    Another LSE run project the PERSEUS project has started to record its documentation online. PERSEUS extends work started in the LSE-ledSECUReProject. In particular the PERSEUS informal update reports which give monthly updates on Shibboleth development progress; and:

    • Shibboleth: Guide for SysAdmins: a presentation is intended to be used as part of the process in which a Shibboleth IdP installation is documented and handed-over from the implementation team (or contractors) to the permanent staff who will need to maintain and support it in the long term

  5. There are a number of JISC Core Middleware and Shared Services Studies, funded alongside the Core Middleware projects, which contain relevant reading, especially:

    • Report on Single Sign-On Technologies

      This is the report on Middleware Study 1 for the Evaluation of Single Sign-on Technologies in response to the JISC ITT for Shared Services and Middleware.

    There is considerable interest world-wide in creating single sign-on systems for the web. These can be considered to be in two distinct classes. The first class is for intra-institutional use, and which could scale up to a size which could cover an entire country. The best known of these systems are Shibboleth from Internet2 in the USA and PAPI from RedIris, the academic network provider in Spain and, of course, Athens in the UK. The second class of system is one that is designed to work primarily in a single institution. The scope of this study is the second class.

    The interest in these systems can be evidenced from the number of systems that have been implemented world wide. Some of these have only been available at a single site but a number of them have already been implemented by a significant number of sites.

    To date there has been no attempt to compare and contrast these various systems. This report describes the University of Edinburghs project to evaluate these systems.

    The UKs interest in the Shibboleth solution led to the consideration of the creation of a standard schema for the description of members of the UK academic communities. The UK however, unlike the USA, already had a tried and tested access management infrastructure in Athens. Thus much of the challenge for the UK lies in persuading the academic community to consider new technology. The UKeduPerson consultation exercise illustrated the depth of this problem and emphasised the need to raise national awareness and sponsor a national debate on the issues.

  6. Eduserv has carried out extensive investigation into Scoping Next Generation Athens Services: SAML and Shibboleth Support in Athens

    In Document version 1.0 plans are discussed to extend the Athens Identity Management System to utilise and interoperate with components in a Shibboleth and/or SAML-enabled infrastructure. This has sometimes been referred to as the Athens-Shibboleth Gateway, but more generally it encompasses the next generation of Federated, or Devolved Authentication (and authorisation) provision within Athens. This document also proposes how additional functionality and flexibility can be delivered to Athens-enabled communities by leveraging Shibboleth protocols.

    The document assumes a familiarity with the concepts of a federated authentication/ authorization model utilised by Shibboleth and AthensDA, and the SAML assertion and protocol specifications. It does not discuss, in detail, specific technologies, but does outline the requirements for AthensDA 2.0.

  7. A useful descriptive article was published in Ariadne, Issue 43, April 2005: Installing Shibboleth by Simon McLeish describes the experience of Shibboleth installation in a Higher Education environment, and suggests ways to make this experience more user-friendly.

  8. In Australia the MAMS project offers step by step instructions on how to install shibboleth origin and target on Debian Linux servers. The aim is to set up a working Shibboleth testbed that is not part of the In Queue Federation but a local Australian federation. They are using themselves as the CA authority.