Phase I -- Understanding the Problem
Use Cases and Technology Recommendations
Phase I of the collaboration involved developing use cases for deploying Shibboleth for accessing protected library resources, with a particular interest in accommodating various user groups -- students, faculty and staff, walk-in library users -- as well as methods for providing remote access for users with university credentials. The collaboration studied the use of Shibboleth, EZProxy, and a combination of the two.
For a comprehensive overview of issues, scenarios and proposed solutions, please see the Phase 1 summary presentation.
What is Shibboleth
Shibboleth is an open-source, standards-based single-sign on technology. Shibboleth provides the ability to access both campus and external applications using a user name and password maintained in a local identity management system administered by a user's institution -- when a user accesses a Shibboleth-enabled resource, the institution provides an anonymous unique identifier to the resource, ensuring user privacy, while permit access to resources based on internally-held criteria. Maintaining user authentication information at the institution allows increased reliability for vendors by ensuring current user affiliation with the institution and reduces the need for password maintenance by the vendor, and need for multiple passwords by the user. For more information on Shibboleth, please see the Shibboleth web page at http://shibboleth.internet2.edu/
Providing Shibboleth Access to Electronic Resources and Library Services
In order to use Shibboleth authentication, both the institution and the vendor need to have Shibboleth implemented. For a list of vendors who are using Shibboleth, and a list of vendors who are affiliated with different federations, please see Resource/Service Providers active in other federations.
- Resource/Service Providers active in other federations (a good starting point to discuss federating with potential sponsored partners)
Basic Implementation: Shibboleth and Rewrite Proxies
EZProxy and other rewrite proxies enable users to access resources that are IP validated. The main advantage to rewrite proxies is that they do not require the user to perform any modifications on their local machine. EZProxy can use Shibboleth to provide initial user authentication, providing a single login for both remote access and campus resources, as well as a seamless user experience when transitioning individual resource access from IP to Shibboleth.
- EZProxy: http://www.oclc.org/us/en/ezproxy/
Background
Use Cases
- Users moving between two campuses (in one university system) -- Cornell
- Serving off-campus library users -- Cornell
- Implementing EZProxy and using it with Shibboleth -- University of California-San Diego
- Migrating to EZProxy and integrating with Shibboleth (moving away from IP-based authentication) -- University of Chicago
- Accommodating Walk-Up Users with Location-Based Authentication -- University of Washington
- Testing EZProxy workflow with EBSCO interface and Shibboleth SessionInitiators -- University of Maryland
- Campus experiences with EZProxy
Presentations
A list of presentations and abstracts, with links to the presentation files can be found here. [This page may need to have it's settings updated for access?]
Joining a Federation
Federations provide a way for member institutions and vendors to define a standard for how Shibboleth authentication information will be transferred between member institutions. This saves time in the vendor negotiation process, as all attributes are agreed upon by the federation members.
- InCommon: http://www.incommonfederation.org/
- JISC: http://www.jisc.ac.uk/federation
- Australian Access Federation: http://www.aaf.edu.au
- Canadian Federation: http://wiki.its.queensu.ca/display/heidm/Canadian+Identity+Management+Federation+%28CIMF%29
Something goes here