University of Washington Institutional Profile
The University of Washington serves 44,000 students on three campuses: UW Seattle, UW Bothell, and UW Tacoma. The Bothell and Tacoma campuses offered only upper division and graduate courses until 2006, when they began admitting freshmen. UW Bothell is co-located with Cascadia Community College. The School of Medicine's WWAMI program provides a specified number of medical school seats to students in Wyoming, Alaska, Montana, and Idaho; these students are UW-enrolled and entitled to UW services. UW's clinical enterprise includes the UW Medical Center, Harborview Medical Center, and a network of neighborhood clinics.
The University of Washington is a research institution with many faculty working from off-campus locations. WWAMI students and medical residents are also geographically distributed and rely on remote access to library resources. In addition to the WWAMI program, many other University departments have ramped up distance education offerings in the last few years.
The University of Washington Libraries operates 16 libraries on the Seattle campus, plus libraries at UW Bothell, UW Tacoma, Harborview Medical Center, and the Friday Harbor Laboratories. The UW Bothell library also serves Cascadia Community College. The Law Library is administratively separate from the University Libraries and operates its own integrated library system. UW is a member of the Orbis Cascade Alliance, a consortium of 35 universities, colleges, and community colleges in Washington and Oregon. The Alliance's Summit union catalog and borrowing system comprises 28.7 million items and 9.2 million titles, with about 380,000 items borrowed per year. The Alliance also brokers contracts for electronic resources, some of which UW purchases.
Electronic resources are generally licensed for all three campuses, and access control is based on IP addresses. As a state institution, UW Libraries provides services and resources to community members while they are physically present at the Libraries' facilities. A small number of resources are limited to students, faculty, and staff only; these resources require authenticated access even from campus IP addresses, or are available only in restricted labs.
The Libraries use Innovative Interfaces' Millennium integrated library system; since April 2007, OCLC's WorldCat Local has been the default public catalog. Offcampus access to electronic resources is mainly via EZProxy. OpenURL link resolution is provided by III's WebBridge module, and holdings data for electronic journals is purchased from Serials Solutions. Most library-provided services that require authentication use the campus single sign-on service "pubcookie"; authorization is done via a locally built web service that obtains real time status information on users from the enterprise directories.
The UW Libraries' interest in a Shibboleth pilot stemmed from our dissatisfaction with location-based access control, a particularly bad fit given our geographically distributed user base. We also wanted to extend our user's single sign-on experience to include remote resources. Our main concern was identifying targets that wouldn't negatively affect the users but would give us some operational experience with Shibboleth.
University of Washington Project Update
Database of Recorded American Music
In 2006, we implemented Shibboleth access to the Database of Recorded American Music (DRAM). At the time, Shibboleth was the only method available for providing offcampus access to DRAM (EZProxy is now supported as well). We delayed our initial implementation until NYU, who was then hosting the service, became a member of the InCommon federation. The UW IdP's attribute release policy sends eduPersonScopedAffiliation to DRAM for eligibility verification, restricting release to the "member" value for current UW students, staff, and faculty.
We require all users, both on and off campus, to authenticate for access to DRAM. Users can browse DRAM, but when they select a stream for playback they are taken to a WAYF screen and then redirected to our WebSSO system. Providing access for walkup users was not deemed necessary, and there was no pushback from campus users about requiring authentication on campus.
DRAM subsequently changed domains and did not continue in InCommon. We continue to use Shibboleth for access to DRAM but must arrange separately for metadata exchange. We have had one service outage, caused by stale metadata; that was resolved as soon as we provided DRAM with current metadata.
RefWorks
In early 2008, UW logins to RefWorks began using Shibboleth and trust metadata provided by the InCommon federation. The UW IdP's attribute release policy sends eduPersonScopedAffiliation and privacy-preserving eduPersonTargetedID values to RefWorks for eligibility verification and record keeping.
Prior to converting to Shibboleth access, users had to create an account that included a username and password. When offcampus, users were required to access RefWorks via EZProxy. Users could create multiple accounts; these secondary accounts provide a way for instructors to share bibliographies with a class, for example. Relatively few users have multiple accounts.
Post-Shibboleth, UW changed its advertised RefWorks URL to avoid the WAYF and take users directly to the UW weblogin service. The RefWorks login page (http://www.refworks.com/Refworks/login.asp?WNCLang=false) added a "Login through your institution" link for Shibbolized access, and UW-specific information was added to the customizable portion of that page.
Users with existing RefWorks accounts were offered the option of Shibbolizing them on initial login. It was not possible to use EZProxy with the Shibbolized accounts, so EZProxy was configured to not proxy any RefWorks access. Only one account per user could be Shibbolized; users with secondary accounts had to continue using RefWorks native authentication with those accounts. Because EZProxy was not proxying RefWorks, those secondary accounts can now only be used from campus IP addresses. RefWorks is looking at how best to support secondary accounts in the Shibbolith environment.
Accommodating Walk-Up Users with Location-Based Authentication
Summary: In some situations it is useful to authenticate user sessions based on location (meaning network address) instead of the more usual credentials (e.g. username and password). An Apache module, mod_auth_location, is available for this purpose.
Most modern application sign-on scenarios operate via credentials associated with and provided by a user: a username and password, Kerberos ticket, X.509 certificate, etc. Use of such credentials permits a user to sign on to a system or service regardless of where the user happens to be. Many institutional systems have worked hard to eliminate the practice of basing access based on location (meaning client machine network address, usually), for various reasons: lack of personal accountability, disconnect with policy, etc.
In one use case, access based on location is exactly what policy calls for. Traditionally, licenses for use of physical library materials have granted access to members of the institution, or any others physically present in the library. As access has moved online it is necessary to continue to support this access policy. Terminals (kiosks) are placed in the library to support both institutional user and library walk-in access.
Many remote vendor-provided licensed resources have had access control set up by location. Typically the licensee institution provides the licensor with its network address ranges, and resources may be accessed from machines in those ranges. Walk-in user access fits in easily with this method. As resources move to using user authentication for access, steps must be taken to preserve walk-in user access. There are a variety of approaches to this, complete discussion of which is out of scope in this document.
From the resource provider point of view, especially for new resources which have never used location-based access, configuring resources for location-based access just to deal with walk-in users is onerous. It is desirable to hide this complexity from the resource provider, and instead handle location-based access as an authentication mechanism at the identity provider (ie the licensee institution).
mod_auth_location from the University of Washington is an extension to the Apache httpd web server for this purpose. It can be configured ...
In an environment using the SAML web browser signon profile (as supported by the Shibboleth system among many other implementations) this permits a location-based walk-in user to appear to a resource provider just as a user-authenticated user does, simplifying resource access setup.
Non-library resources
UW is also using Shibboleth for access to resources and services outside the library sphere. A list of SP's with whom we are interoperating is available at http://www.washington.edu/computing/infra/shibboleth/sp.html