University of Chicago Institutional Profile
Situation / background
The University of Chicago is a research and educational institution in Chicago with approximately 2,100 faculty and other academic personnel, 4,900 undergraduate students, and 9,800 graduate, professional, and other students.
The University of Chicago Library is one administrative unit with six locations on the main campus.
The Library licenses or otherwise provides a large number of electronic resources, both through its own subscriptions and through consortial arrangements. Typically, licensed electronic resources are available to faculty, students, staff, and anyone who is physically present in a Library location.
The UofC Library currently uses the Horizon integrated library system to maintain the majority of it's collections, uses SFX and Metalib to facilitate access to electronic resources, and has implemented AquaBrowser (locally branded as "Lens") as a local discovery tool to bring together diverse resources. The campus runs EZproxy to proxy access to IP-authenticated resources.
Issues to solve with pilot:
- Access to licensed library resources and services.
- Access to locally-hosted resources at U. Chicago that must not be accessible by the world
Challenges
IP-authenticated resources have not required on-campus users to authenticate themselves, and there is a reluctance to inconvenience on-campus users in a Shibboleth environment. How to accommodate this desire is a technical challenge, but changing the experience for on-campus users is a political issue.
University of Chicago Project Update
Pilot Description
The U. Chicago pilot involved migrating from the Squid proxy to EZproxy.
Early Shibbolet testing was done with EBSCOhost, ILLiad was the first production service, and EBSCOhost, ScienceDirect, Scopus, and ARes planned for fall.
Integration: Library-controlled services such as the catalog, AquaBrowser, SFX and Metalib, all are configured to rewrite URLs to all resources to route access through the proxy server. Not all resources require authorization, so if a resource is not in EZproxy's configuration file, the proxy server will forward the browser directly to the remote service, stepping out of the interaction entirely. If a service is in the configuration, EZproxy is configured to first allows IP-based authentication for proxying if the user is on campus. For off-campus users, the proxy requires authentication with a University ID. Given successful authentication, the proxy checks the user's attributes to see whether they are allowed access to a particular resource. As we move resources to Shibboleth, we expect that EZproxy will also step out of the loop, and not proxy access to Shibbolized resources.
Initially, the proxy server was configured to perform LDAP- based authentication. At that time, everyone in LDAP was eligible to use these resources through the Library's licensing; authentication was equivalent to authorization. However, as the University moved to fully integrate the campus ID namespace and include the Hospitals, Laboratory School, and alumni in campus authentication services, the equivalence of authentication and authorization would be broken. We had been planning with this in mind, and EZproxy was configured to authenticate via our Web ISO and use our Shibboleth IdP for authorization. EZproxy checks user attributes against the resource they are accessing, and allows or disallows access accordingly.