David Kennedy
University of Maryland
August 1, 2007
In this experiment, I tested the workflow, which was put forth by the InCommon Library Services Working Group, for seamless authentication into Shibboleth-protected licensed library resources. The workflow is designed to handle links generated from many places, including OpenURL resolvers, gateways to online resources, class pages in Blackboard, faculty-created links, etc. To be considered successful, these links need to be relatively easy to generate.In brief, the workflow involves links generated to the licensed resource through a URL rewriting proxy, the URL rewriting proxy redirecting those links to SessionInitiator at the licensed resource, and the licensed resource seamlessly redirecting to the proper institution's Identity Provider for authentication.For this experiment, I tested with ezproxy BETA 4.2a, shibboleth identity provider v. 1.2.1a for Universityof Maryland, College Park, and EBSCO as licensed resource/Service Provider. I also tested links generated from an OpenURL resolver, SFX, and from a gateway to library resources, Metalib.
For the purpose of this experiment, I isolated each piece of the workflow separately, and eventually tested ezproxy and EBSCO in a real library environment. Below are the steps I took in testing:
I installed a 1.3f Service Provider on biblos.umd.edu. The service provider was configured with two endpoints, /cgi-bin/printenv and /secure, and one SessionInitiator, /Login. I configured the Service Provider to trust three identity providers, urn:mace:incommon.umd.edu, urn:usmai:cp:logintest.lib.umd.edu, and urn:usmai:hs:logintest.lib.umd.edu.I wanted to create URLs that would eventually resolve to the endpoints, but would force authentication to the proper IdP, without explicitly asking the user to identify where they were from.
Some of the links I used:
SessionInitiators behaved as expected, redirecting through proper IdP and on to proper endpoint after authentication.
I tested the SPUEdit directives for a) that they redirected properly according to the regular expressions, b) that the session was not proxied, and c) that ezproxy did not force authentication. I configured ezproxy's shib.usr to deny all proxying. I configured a few simple SPUEdit directives. I tested these and verified that I was redirected to the proper URLs, my session was not proxied with ezproxy, and I was not prompted to log in.
Further, I tested SPUEdit IP directives in order for ezproxy to selectively redirect on-campus and off-campus traffic. Specifically, I tested creating an on-campus range of IPs with ExcludeIP directives, and creating SPUEdit -ExcludeIP directive. Tested the behavior within and outside the defined range.
Example:
ExcludeIP 129.2.16.108-129.2.16.108
SPUEditVar provider=urn:usmai:cp:logintest.lib.umd.edu
SPUEdit -ExcludeIP @^https?://.\.ebscohost\.com/.$@http://abc.com/target=$0@irs
SPUEdit @^https*://.\.ebscohost\.com/.$@http://def.com/target=$0@irs
Option LogSPUEdit
In this step, I used the Service Provider and ezproxy from the previous two steps. The service provider was running at https://biblos.umd.edu:4243, and the ezproxy was running at http://biblos.umd.edu:2048. The goal here was to create simple ezproxy urls to get to my shibboleth-protected endpoints, and force authentication to the correct IdP seamlessly.
I chose two endpoints:
https://biblos.umd.edu:4243/secure
https://biblos.umd.edu:4243/cgi-bin/printenv
I configured SPUEdit in ezproxy.cfg to use the SP's SessionInitiator. In our environment, as I suspect in most environments, a single ezproxy instance serves one institution, and so I hard-coded the Identity Provider's providerId into the SPUEdit directive. I tested with three different providerIds.
SPUEdit @^https://biblos\.umd\.edu:4243/.*$@https://biblos.umd.edu:4243/Shibboleth.sso/Login?providerId=urn:usmai:cp:logintest.lib.umd.edu&target=$e0@irs
Then, I created simple ezproxy urls to reach my endpoints:
http://biblos.umd.edu:2048/login?url=https://biblos.umd.edu:4243/secure
http://biblos.umd.edu:2048/login?url=https://biblos.umd.edu:4243/cgi-bin/printenv
In this stage, I tested Shibboleth authentication to EBSCO resources via Session Initiator that EBSCO configured into their Service Provider. I tested linking to an online database, Academic Search Premier, and linking directly to a Full Text Journal, Journal of Financial and Quantitative Analysis. I configured the IdP to release eduPersonScopedAffiliation. I edited our EBSCO account to map valid Affiliations to our account.
I tested with the following URLs:
(Academic Search Premier)
https://shibboleth.ebscohost.com/Shibboleth.sso/Login?providerId=urn:usmai:cp:logintest.lib.umd.edu&target=http%3A//shibboleth.ebscohost.com/login.aspx%3Fauthtype%3Dshib%26profile%3Dehost%26defaultdb%3Daph
(Journal of Financial and Quantitative Analysis)
https://shibboleth.ebscohost.com/Shibboleth.sso/Login?providerId=urn:usmai:cp:logintest.lib.umd.edu&target=http%3A//search.ebscohost.com/direct.asp%3Fdb%3Dbuh%26jn%3DFQA%26scope%3Dsite
EZproxy and the SP were able to resolve to the proper endpoints and provide the proper authentication without user interaction.
I configured ezproxy to take advantage of EBSCO's SessionInitiators in order to create more simple links to the above endpoints, and maintain the same functionality (seamless authentication). I configured the following SPUEdit directive in ezproxy:
SPUEdit @^https*://.\.ebscohost\.com/.$@https://shibboleth.ebscohost.com/Shibboleth.sso/Login?providerId=urn:usmai:cp:logintest.lib.umd.edu&target=$e0@irs
I then tested the following ezproxy urls:
http://biblos.umd.edu:2048/login?url=http://shibboleth.ebscohost.com/login.aspx?authtype=shib&profile=ehost&defaultdb=aph
http://biblos.umd.edu:2048/login?url=http://search.ebscohost.com/direct.asp?db=buh&jn=FQA&scope=site
Test ezproxy/EBSCO in a real library environment
In this stage, I tested all of the pieces together by installing the ezproxy instance into an environment where it was integrated with a library catalog (ALEPH), an OpenURL resolver (SFX), and a gateway/metasearch tool (Metalib). I configured this ezproxy instance with the same SPUEdit directive as in previous test. I also modified the database links in metalib to reflect the new login syntax.
For instance, I changed the Business Source Premier URL from
http://search.ebscohost.com/login.aspx?authtype=ip,uid&defaultdb=buh&profile=ehostto
http://shibboleth.ebscohost.com/login.aspx?authtype=ip,shib&defaultdb=buh&profile=ehost
Both SFX and Metalib are aware of ezproxy and know how to generate URLs through ezproxy. They are also both aware of a user's IP address and can be configured to recognize when a user is on-campus as opposed to being off-campus. In our environment, Metalib and SFX redirect on-campus users directly to online resources and off-campus users through ezproxy. So, besides the URL changes to the EBSCO databases, no other changes were necessary to SFX or Metalib.
Tested accessing EBSCO resources through Metalib and SFX. All tests were successful.
The goal of this experiment was twofold: 1) to test a method for providing seamless authentication to library-licensed online resources, and 2) to test that this method would integrate with existing library technology and allow relatively easy creation of authenticated URLs to library-licensed online resource. In both cases, this experiment was successful.
Using EBSCO online resources as an example, we were able to take a user from an OpenURL resolver or online gateway directly to the resource without ever asking the user to identify where they were from or ask the user to log in more than once. And, so we were able to provide seamless authentication to resources.
For the second part of the goal, we tested SFX and Metalib as existing library technology. SFX and Metalib are not unique in their category of software in that they are aware of ezproxy, and that they can act according to a user's location. Very little, if any, configuration needed to be done to the existing library software in order to provide access to EBSCO online resources.
In terms of ease of URL creation, a user, say a faculty member, could take a known URL for an online resource, and simply tack an ezproxy prefix (ex. http://biblos.umd.edu:2048/login?url=) to the beginning of the known URL.
For Resource Providers:
For Library Software Admins: