Table of Contents
This document aims to set out the requirements for using Shibboleth in its simplest context. Access to electronic journals does not require complex authorisation decisions – in general only an assertion that the accessor is affiliated to a particular institution is needed – and so the issues of authorisation attribute storage and aggregation, and the complexities they entail, do not arise.
Shibboleth is a distributed authorisation project that has been developed by a federation of higher education establishments in the United States called Internet2. Shibboleth is not an authentication or authorisation scheme. It is an open, standards-based protocol for securely transferring attributes between an identity provider (local institution) site and service provider (resources) site which is supplied as an open-source reference software implementation.
Academic libraries licence and offer access to a range of online resources that are regarded as necessary to support research and teaching in any subject. One of the big issues to be solved is maintaining a balance between adhering to the legal and contractual responsibilities to publishers (to limit access to only those users covered by licence terms) and to the library's users (to keep personal information secure), and, finally, to ensure the fundamental function of a library operates - that users are shown the simplest path to the information they want[1].
E-journals are journals in either full or partial text found online; in academic institutions access to these is usually managed by a library. Most journals require a subscription, but some are accessible at no cost. Some e-journals are found only electronically; a large number of titles are published in both paper and electronic versions. E-journal providers can be divided into two categories: publishers and aggregators.
Most e-journal publishers provide access to their titles directly from their websites; some journal publishers make their e-journals available only on their own sites (e.g. Royal Society of Chemistry[2]).
Aggregator services offer access to e-journals from publishers that they have negotiated with. They will organise e-journals access, and administer passwords, IP address access, table of contents services, usage statistics and archiving. Moreover, users benefit from using a single interface. Examples of these services are SwetsNet[3] and Ebsco Online[4]. There are also companies which deal specifically with e-journals access, such as Ingenta[5].
In order to Install and manage a Shibboleth software implementation you will need to be able to access the following skills:
-
A reasonable working knowledge of the Linux (or Unix) Command Line Interface (CLI);
-
Knowledge of how to use the apache web server, either the 2.0.* or 1.3.* versions;
-
Familiarity with the concepts of https communication (certificates, keys and the like);
-
Familiarity with firewalls or access to someone who is familiar, in particular with Linux iptables style firewalls;
-
Familiarity with the setup of Windows Active directory, or access to someone who has those skills;
-
Importantly, a willingness to read around subject areas, management pages and mailing lists, since this is an emerging and swiftly developing area.
There are several essential elements that must be present in the environment to ensure Shibboleth functions well (see section 2). Shibboleth is entirely written in Java on the Identity Provider side. The basic installation of the Shibboleth Identity Provider should be carried out before joining a federation, as the latter will test that the installation works, and will require information that will not be available until installation is complete.
The process is as follows:
-
User requests resource
-
Request is redirected to WAYF (which can be hosted by the Federation)
-
The user selects their home institution from the list provided by the WAYF, which then redirects the request to the Identity Provider at that institution
-
The user authenticates at their home insitution via the WebISO (see below)
-
If authentication is successful a handle (digitally signed certificate) is passed to the Service Provider
-
The handle goes back to the Identity Provider to request attributes for authorisation
-
The requested attributes are returned to the Service Provider
-
If the attributes are acceptable, then access to the resource is authorised
The Identity Provider deals with authentication and the Service Provider has responsibility for authorisation. Shibboleth interactions are shown in full in Figure 2 on page 6 of the SWITCH publication AAI System and Interface Specification, available from http://www.switch.ch/aai/docs/AAI_System_Specs.pdf
[1] For additional information see Paschoud, J. (2005) Shibboleth and SAML: at last, a viable global standard for resource access management. New Review of Information Networking Vol. 10, No. 2. (November 2004), pp. 147-160