UCSD Institutional Profile
Situation / background
The University of California San Diego serves approximately 27,000 undergraduate and graduate students in San Diego, California. The campus consists of the main campus site in La Jolla, the Scripps Institute of Oceanography and the UC San Diego medical center in Hillcrest. All campuses are within a single city and the network IP addresses are administered by the University's central IP department.
The UC San Diego library is a collection of ten campus libraries, five within the main campus library building, and the others located on the main campus. UC San Diego is part of the larger University of California system, which consists of 10 campuses plus the UC Office of the President (UCOP)/California Digital Libraries (CDL). UC San Diego locally purchases many electronic resources, however other resources are purchased in cooperation with other UC Campuses, and yet others are licensed by CDL on behalf of the entire system.
Walk-ins
UC San Diego is a state institution and provides library services to community members who are present at the library's facilities. Some electronic and data resources are limited to students and faculty only, and these resources are accessible only from restricted labs.
Electronic Resource environment
UC San Diego uses the Innovative Interfaces (III) integrated library system. III includes the public access catalog, the acquisitions module and the electronic resources management module. The ILS and ERM software used is unique and maintained per-campus in the UC system.
The University of California uses SFX for managing open URL/link resolver access for all campuses in the system. System-wide resource access is maintained centrally, although each campus also maintains separate instances within the shared database to reflect variations in local holdings, local purchases and campus-specific URL access.
Remote access
UC San Diego is a research institution with many faculty working at remote sites. In particular, clinical faculty often work at clinical sites that do not permit easy configuration of local computers. As well, there is a high amount of usage of library electronic resources from off-campus for both commuter and distance education students.
At the beginning of the pilot period, UC San Diego used two mechanisms for providing authenticated remote access to resources for UC San Diego students and faculty: a traditional (Squid) proxy and the Cisco VPN client. These systems are maintained by central campus IT. Both systems assign a known campus IP address to an off-campus computer's web session. To use the proxy or VPN, users must configure their home machine and/or install client software, and login to the system using their UCSD campus mail user name and password (Kerberos), which is currently different from the Active Directory and SSO login settings. The Squid proxy primarily contains URL's to provide access to library electronic resources.
In May 2008, central IT rolled out an updated Cisco VPN client as well as the WebVPN product, creating a rewrite-proxy alternative to Squid. At this point, these newer Cisco products are not integrated with single sign on (they use the campus Active Directory login information), although IT is investigating integration with Shibboleth single-sign on.
Shibboleth configuration
UC San Diego implemented Shibboleth in 2005 in response to the system-wide UC Trust initiative and requirement for accessing UC internal resources and tools. Shibboleth has been used for many UCSD campus resources since then, including leave balances, travel, finance, Shibboleth enabled campus services, housing and recreation.
Issues to solve with pilot
Current methods of remote access have a number of issues that we hoped to address through our work in the Library / Shibboleth pilot.
- Reduce need for user configuration of computers to provide remote access (user error, firewall/machine conflict, lockdown machines).
- Reduce need for IP maintenance with vendors
- Reduce need for manual proxy maintenance
- Create consistent user experience, using a single user name and password to access both internal campus resources, library services and external library-licensed electronic resources.
Challenges
We had a number of initial concerns and scenarios to explore with the pilot:
- Finding a solution that would work for walk-in users.
- Minimizing changes in current user experience for on-campus and remote access.
- Getting familiarity with and implementing EZProxy
- Compatibility in a consortial environment with shared resources and shared tools.
- Possibility of integrating Cisco WebVPN as an alternative rewrite proxy solution.
UCSD Project Update
UCSD Project Update - 8/7/08
Pilot Description
The UC San Diego Libraries enabled Shibboleth access to JSTOR and ScienceDirect very early on (2006), however, this access had never been put in production and was used for pilot purposes and as an alternative access method for selected users.
We created an instance of EZProxy, enabled for authentication with Shibboleth. This instance is currently maintained within Library IT, and was populated with the configuration file from UC Santa Cruz (our earliest UC EZProxy adopter), which resulted in quick configuration of a large number of UCSD's accessible resources.
As EZProxy was not a production system, we were reluctant to make changes in our publically available catalog, web pages and other finding aids that would manually divert access to the pilot proxy. Instead, we added the library web page, catalog and SFX to the EZProxy configuration file, permitting continued use by a user once they entered the system either through manual login or through use of the JavaScript bookmarklet. Surprisingly, addition of SFX to our EZProxy configuration file appears to have bypassed the need to set the prepend setting in SFX -- as invoking SFX does not break the EZProxy chain, users are passed through SFX to the target resource and maintain their EZProxy authentication.
For the most part, the issues with configuration are more dependent on EZProxy than with Shibboleth, with the exception of individual product results (below).
We were concerned with providing better campus and walk-in access, but have not implemented any system. In addition to the mod_auth_location solution pioneered by the University of Washington,, our central IT has an additional location detector workaround.
Library Resources Shib-enabled
- JSTOR
- ScienceDirect
- EZProxy
- DAMS (local repository)
Results
User experience
Library Services
ILS integration is currently not implemented and is still in the discussion stages with the vendor
Library Resources
Screenshots should be included here, or as part of the general overview depending on the commonalities between campus experience.
Shib-enabled resource
Direct
1. Go to website
2. Click login
3. Select WAYF
4. Login SSO
5. Validation screen
6. Access resource
Through EZProxy
1. Login to EZProxy (using Shibboleth login)
2. Go to resource website
3. Click Login
4. Select WAYF
5. Validation screen (no login)
6. Access resource
Link Resolver
Same as above scenarios, however, if resource does not have an easy way to start the login process from the linked page, the user will not be able to authenticate with Shibboleth.
IP-enabled Resource
On Campus
As we are not automatically routing everything through EZProxy, on-campus access occurs solely through vendor IP validation.
Off Campus
1. User gets into proxy process through bookmarklet on web page or when accessing resource page directly.
2. Login SSO
3. Validation Screen
4. Access resource
Link Resolver
1. User gets into proxy process through bookmarklet on web page or when accessing resource page directly.
2. Login SSO
3. Validation Screen
4. Access resource 1
5. Locate OpenURL resource (full text on resource 2)
6. UCElinks (SFX) page
7. Access resource 2
Lessons learned
Questions answered
- EZProxy was much easier to implement than originally anticipated.
Questions raised
- EZProxy variations: As much of the user experience and general maintenance issues are affected by the EZProxy implementation, we need to know more about best practices for general EZProxy configuration.
- Inconsistency with finding login: The vendor implementations of Shibboleth vary widely. Some resources provide an easy link from all pages to log in using Shibboleth (ScienceDirect), others require a specific URL to provide access to the Shibboleth login option (EBSCO). To provide an easy transition from IP to Shibboleth (and to prevent additional maintenance/updating of access points), getting to a Shibboleth login should be easily accessible from any page on the vendor site.
- Inconsistency with WAYF: Another factor of the varied implementations are the different WAYF pages implemented by different vendors (compare ScienceDirect and JSTOR). The variations in interface, location and selection should be more standardized to prevent user confusion.
- Bypassing WAYF: To permit easier transition of IP based authentication to Shibboleth authentication, more work needs to be done to provide a WAYF-less environment, particularly if the user is already authenticated with Shibboleth in the browser session or is accessing from on-campus (see Shibboleth Enabled Resource - Off Campus above).
- Personalized functionality: One of the primary arguments of why the Shibboleth + EZProxy solution is better than EZProxy alone is the ability to access personalized functionality at the vendor. Very few vendors have implemented this yet.
Recommendations for others
- The biggest surprise for us was the advantage of configuring our access points (catalog, resource database, SFX) in EZProxy - this reduced our setup time and maintenance issues considerably. I'm not sure if this is common practice, but it worked well for us.
- The JavaScript bookmarklet is great for reinstating proxy access.
Next steps
- As WebVPN appears to be an inevitability on our campus, we are looking to use what we've learned working with EZProxy and apply it to the WebVPN scenario to see if we can get this to work.
- Activate Shibboleth for remaining InCommon resources.
- Test performance impact for routing all activity through rewrite proxy: in our interest to reduce our need to maintain IP's.
- We are Interested in seeing how to integrate EZProxy more easily into off-campus experience -- providing a link on the webpage, distributing the bookmarklet.
- Investigate/validate our implementation against information in EZProxy forums to find out more about the configuration scenarios and implications..
- Verify options for using WebVPN access for resources that do not permit remote access. Currently, we exclude the Proxy/VPN IP range fin the lists we provide to these vendors, however, there may be a mechanism to restrict access within the configuration file.
- Small-scale user pilot with Biomed faculty to test the lockdown/remote scenario.
- We're also interested in the application of the SSO proxy solution to restrict access to affiliated users only. (We have very few resources that prohibit access by walk-in users, but those have a pretty high maintenance overhead.)
All this is on hold until after meeting with WebVPN in late August.