The following four requirements have to be met in order for users to be able to gain access to e-journals via a Shibboleth connection in its simplest context.
Shibboleth requires a local method to authenticate users. Single Sign-On allows users to provide their username and password once to a trusted service and to have their identity securely, consistently and seamlessly provided to many other web applications.
An open-source WebISO solution, Pubcookie, can be obtained from http://www.pubcookie.org/, which also has documentation to describe the installation process. An installation guide detailing set up on Redhat AS 3.0 with authentication against Windows Active Directory is available from http://iamsect.ncl.ac.uk/deliverables/. The minimum requirement is for the WebISO to be able to authenticate browser users and supply their identity to the Handle Service (see section 2.3 below).
The Pubcookie login server has to be a standalone dedicated secure web server that only serves pubcookie login requests; it should not be used for other secure web serving or for other tasks. The server will form the main gateway for web-based login, so it is imperative that it is as secure as possible. It should therefore have as few applications running as possible in order to reduce the number of potential exploits.
Newcastle University has chosen to use Pubcookie, but Yale CAS[6] is also common as it comes as a component of UPortal. The LSE uses Yale CAS and as part of the SECURe deliverables an installation guide, available at: http://www.angel.ac.uk/SECURe/deliverables/documentation/directory.html, was published.
The WebISO uses local directory services (see section 2.2 below) to authenticate the user, challenging for username, password, digital certificate, smartcard, biometric identification, or whatever the institution routinely accepts for authentication. However, this only occurs if this is the first authentication request of the session, thus single sign on is achieved.
Kerberos is another network authentication protocol. It is designed to provide authentication for client/server applications by using secret-key cryptography. An open source implementation of this protocol is available from the Massachusetts Institute of Technology (MIT[7]). The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. Some reports state that 'Kerberos can already complement or enhance the deployment of Shibboleth ... standards'[8]
Shibboleth also requires a source of authentication from a common institutional directory service. Many institutions will already be using the Windows Active Directory for user authentication and Pubcookie or Yale CAS provide a flexible layer on top to provide web based secure single sign on.
Windows Active Directory directory service is a distributed directory service that is included with Microsoft® Windows Server 2003 and Microsoft® Windows 2000 Server operating systems[9]. A directory service provides a centralised location to store information in a distributed environment about networked devices and the people who use them. A directory service also implements the services that make this information available to users, computers, and applications. The Active Directory service is both a database storage system (attribute store) and a set of services that provide the means to securely add, modify, delete, and locate data in the attribute store. The minimum requirement is that user IDs need to be mapped to user attributes.
The most common alternative directory service is the LDAP (Lightweight Directory Access Protocol) directory, typically used to store information about entities such as people, offices, machines, but can be used to store information about anything described by a set of attributes. Being a protocol, it can be implemented in any way, as long as the protocol is adhered to. There are a number of implementations to choose from, including the open source OpenLDAP[10] from the University of Michigan; Oracle's[11] LDAP server that runs on top of an Oracle database. Sun One[12] (previously known as iPlanet) and the Novell LDAP services for e-Directory[13] are two more examples of software running the LDAP protocol.
Shibboleth has a complex architecture with a large number of components, but can basically be divided into two: the Identity Provider (origin) and the Service Provider (target). The Service Provider protects the resource, while the Identity Provider ensures that users are authenticated and passes on their attributes to the Service Provider on request.
The Shibboleth Identity Provider has two components, the handle service (HS) and the attribute authority (AA) (see Figure 1). The handle service is the component of Shibboleth through which the user authenticates. Typically, they will be redirected to it by a Shibboleth Service Provider via a WAYF ('where-are-you-from' servicZetoc Searche) provided by an institution or a federation of institutions of which the user's institution is a member. The AA retrieves information about the user from the institutional directory system (the source of authentication mentioned in 2.2) or other attribute store, and forwards these to the Service Provider according to the identity provider attribute release policy.
In the Shibboleth architecture, the identity provider must have an X.509 server certificate for use in authenticating the servers to each other. This should be issued by a commonly accepted Certification Authority (such as Globalsign[14]), which may be stipulated in Federation rules. In theory, Shibboleth can accommodate certificates from any trusted source (e.g. a commercial CA or an ad hoc institutional CA). It is important to note that, when setting up the identity provider, you need to know which CA your chosen federation(s) will accept. In practice, management of a federation will be easier if all institutions get certificates from the same trusted source. For example, in the SDSS Federation[15] (see 2.4.1), this source is either Globalsign or, for development sites, the SDSS internal certificate service.
A guide to installing Shibboleth Identity Provider on Redhat AS 3.0 is provided as part of the IAMSECT deliverables at http://iamsect.ncl.ac.uk/deliverables/.
A federation is a group of institutions and resource/ service providers who have common policies (often expressed in a trust agreement) which allow them to access the same online resources. In so doing, they must implicitly or explicitly agree to a common set of guidelines.
In a Higher Education Federation, users will usually come from identity provider institutions, which will host the Shibboleth identity provider server and supply the source of authentication. In the case of access to e-journals, the federation also needs to include the journals required by the users as service providers.
Joining a federation is not necessary for the deployment of Shibboleth, but joining one will dramatically increase the number of resource providers available to users without having to enter into a bilateral agreement with each one.
There are examples of production federations in Finland, Switzerland and the USA, see An introduction to Shibboleth Federations at http://iamsect.ncl.ac.uk/deliverables/ for more detail.
The SDSS Federation (www.sdss.ac.uk) has several resources set up for a Shibboleth Identity Provider to target; these currently include the EDINA resources BIOSIS (life sciences), EMOL (film and video), UPDATE (farming, environment) and the Education Image Gallery plus the MIMAS hosted Landmap (satellite image and digital elevation data for the British Isles) and Zetoc Search (British Library Electronic Table of Contents), and the Internet2 Shibboleth Wiki. The federation also contains 7 identity providers and 8 JISC Core Middleware projects, including AMIE, SDSS, SPIE.
Once the prerequisites of installing an Identity Provider and obtaining an X.509 certificate have been met, there is a simple email form to complete to apply to join the SDSS federation as an identity provider (origin site)[16]. SDSS Wiki Documentation[17] explains how to configure the Shibboleth Identity Provider to take part in the federation. This document also describes the steps an identity provider needs to take to generate the eduPersonScopedAffiliation attribute automatically (without an attribute store) by setting the required scope in resolver.xml.
In the UK it would be practical for institutions wishing to complete the Shibboleth installation process in the near future to join the SDSS Federation. The current administration of SDSS is scalable to all UK institutions. SDSS is not a production federation (see 2.4.2), instead it offers a robust enough trust system for delivery of licensed content, but with fairly low entry requirements to encourage the participation of development projects.
Currently:
all members of the federation are required to observe best practice in the handling and use of digital certificates and private keys.
all identity providers (origins) must make reasonable attempts to ensure that only members of their institution are provided with credentials permitting authentication to the handle server, and that the assertions made to service providers by the attribute authority are correct.
all service providers (targets) must agree not to aggregate, or disclose to other parties, attributes supplied by identity providers.
This issue is currently (June 2005) out to consultation in the interested community. Practical and policy issues underpinning the formation of a single production Shibboleth federation in the UK HE and FE communities have been outlined in a blueprint paper. An advisory board has also been set up to recommend the appropriate action to be taken by JISC to set up the federation following the conclusion of the consultation process. The aim is to write a set of drafts for more detailed policy papers by July 2005; realisation of these plans should occur in Autumn 2005.
Organisations (such as the early adopter projects and IAMSECT) currently using one of the pilot federations, run by Eduserv or SDSS, would be able to transfer to the production federation in 2005/6. This would populate the federation with enough members to be the main environment for use by institutions of all kinds.