Date: Thu, 28 Mar 2024 22:40:20 +0000 (UTC) Message-ID: <788720156.7121.1711665620165@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7120_1974097490.1711665620164" ------=_Part_7120_1974097490.1711665620164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
David Kennedy
University of Maryland
August 1, 2007
In this experiment, I tested the workflow, which was put forth by the In= Common Library Services Working Group, for seamless authentication into Shi= bboleth-protected licensed library resources. The workflow is designe= d to handle links generated from many places, including OpenURL resolvers, = gateways to online resources, class pages in Blackboard, faculty-created li= nks, etc. To be considered successful, these links need to be relativ= ely easy to generate.In brief, the workflow involves links generated to the= licensed resource through a URL rewriting proxy, the URL rewriting proxy r= edirecting those links to SessionInitiator at the licensed resource, and th= e licensed resource seamlessly redirecting to the proper institution's Iden= tity Provider for authentication.For this experiment, I tested with ezproxy= BETA 4.2a, shibboleth identity provider v. 1.2.1a for Universityof Marylan= d, College Park, and EBSCO as licensed resource/Service Provider. I a= lso tested links generated from an OpenURL resolver, SFX, and from a gatewa= y to library resources, Metalib.
For the purpose of this experiment, I isolated each piece of the workflo= w separately, and eventually tested ezproxy and EBSCO in a real library env= ironment. 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 c=
reate URLs that would eventually resolve to the endpoints, but would force =
authentication to the proper IdP, without explicitly asking the user to ide=
ntify where they were from.
Some of the links I used:
SessionInitiators behaved as expected, redirecting through proper IdP an= d on to proper endpoint after authentication.
I tested the SPUEdit directives for a) that they redirected properly acc= ording 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 dir= ectives. I tested these and verified that I was redirected to the pro= per URLs, my session was not proxied with ezproxy, and I was not prompted t= o log in.
Further, I tested SPUEdit IP directives in order for ezproxy to selectiv= ely 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=3Durn:usmai:cp:logintest.lib.umd.edu
SPUEdit -ExcludeIP @^https?://.\.ebscohost\.com/.$@ht=
tp://abc.com/target=3D$0@irs
SPUEdit @^https*://.\.ebscohost\.com/.$@http://def.com/target=3D$=
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-protect= ed endpoints, and force authentication to the correct IdP seamlessly.
I chose two endpoints:
https://biblos.umd.edu:4243/secure
ht=
tps://biblos.umd.edu:4243/cgi-bin/printenv
I configured SPUEdit in ezproxy.cfg to use the SP's SessionInitiator.&nb= sp; 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 differe= nt providerIds.
SPUEdit @^https://biblos\.umd\.edu:4243/.*$@https://biblos.umd.edu:4243/= Shibboleth.sso/Login?providerId=3Durn:usmai:cp:logintest.lib.umd.edu&ta= rget=3D$e0@irs
Then, I created simple ezproxy urls to reach my endpoints:
http://biblos.umd.edu:2048/login?url=
=3Dhttps://biblos.umd.edu:4243/secure
http://biblos.umd.edu:2048/login?url=3Dhttps://biblos.umd.ed=
u: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 linki= ng directly to a Full Text Journal, Journal of Financial and Quantitative A= nalysis. I configured the IdP to release eduPersonScopedAffiliation.&n= bsp; I edited our EBSCO account to map valid Affiliations to our account.&n= bsp;
I tested with the following URLs:
(Academic Search Premier)
https://shibboleth.e=
bscohost.com/Shibboleth.sso/Login?providerId=3Durn:usmai:cp:logintest.lib.u=
md.edu&target=3Dhttp%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=3Durn:usmai:cp:logintest.lib=
.umd.edu&target=3Dhttp%3A//search.ebscohost.com/direct.asp%3Fdb%3Dbuh%2=
6jn%3DFQA%26scope%3Dsite
EZproxy and the SP were able to resolve to the proper endpoints and prov= ide the proper authentication without user interaction.
I configured ezproxy to take advantage of EBSCO's SessionInitiators in o= rder to create more simple links to the above endpoints, and maintain the s= ame functionality (seamless authentication). I configured the followi= ng SPUEdit directive in ezproxy:
SPUEdit @^https*://.\.ebscohost\.com/.$@https:= //shibboleth.ebscohost.com/Shibboleth.sso/Login?providerId=3Durn:usmai:cp:l= ogintest.lib.umd.edu&target=3D$e0@irs
I then tested the following ezproxy urls:
htt=
p://biblos.umd.edu:2048/login?url=3Dhttp://shibboleth.ebscohost.com/login.a=
spx?authtype=3Dshib&profile=3Dehost&defaultdb=3Daph
http:=
//biblos.umd.edu:2048/login?url=3Dhttp://search.ebscohost.com/direct.asp?db=
=3Dbuh&jn=3DFQA&scope=3Dsite
Test ezproxy/EBS= CO in a real library environment
In this stage, I tested all of the pieces together by installing the ezp= roxy instance into an environment where it was integrated with a library ca= talog (ALEPH), an OpenURL resolver (SFX), and a gateway/metasearch tool (Me= talib). I configured this ezproxy instance with the same SPUEdit dire= ctive as in previous test. I also modified the database links in meta= lib to reflect the new login syntax.
For instance, I changed the Business Source Premier URL from
http://searc= h.ebscohost.com/login.aspx?authtype=3Dip,uid&defaultdb=3Dbuh&profil= e=3Dehostto
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 u= sers directly to online resources and off-campus users through ezproxy.&nbs= p; So, besides the URL changes to the EBSCO databases, no other changes wer= e necessary to SFX or Metalib.
Tested accessing EBSCO resources through Metalib and SFX. All test= s were successful.
The goal of this experiment was twofold: 1) to test a method for providi= ng 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 on= line 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 l= og in more than once. And, so we were able to provide seamless authen= tication to resources.
For the second part of the goal, we tested SFX and Metalib as existing l= ibrary technology. SFX and Metalib are not unique in their category o= f software in that they are aware of ezproxy, and that they can act accordi= ng 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 EBS= CO online resources.
In terms of ease of URL creation, a user, say a faculty member, could ta= ke a known URL for an online resource, and simply tack an ezproxy prefix (e= x. http://biblos.umd.edu:2048/login?url=3D) to the beginning of the k= nown URL.
For Resource Pro= viders:
For Library Soft= ware Admins: