EZproxy and Summon

I’ll flesh out this blog post later on today, but just wanted to post some screenshots (partly as a rebuttal to Nicole’s blog post “Some thoughts about (authentication) discovery aimed at librarians“) to show how well EZproxy fits as the authentication layer between a discovery service (such as Summon) and journal articles on publisher sites.

As Nicole well knows, I’m not a librarian and I couldn’t give two hoots about the “official CILIP endorsed librarian way of doing things” (n.b. my quote, not Nicole’s) when it comes to e-resource access. All I care about is trying to get the user to where they want to be (e.g. the full text of a journal article) with the least number of mouse clicks, and the least amount of swearing, frustration and death-threats against the library for making it so flippin’ difficult ;-D

[edit] Apologies — I didn’t mean to imply that librarians don’t care about users. I just took offence when I felt Nicole’s post implied this was a librarian problem and/or that librarians were the root cause of the problem. As I’m not a librarian myself, I felt it was wrong to infer that anything I say or do is endorsed by, or represents, librarianship in general, or is the way a librarian would choose to do it. To the best of my knowledge, librarians perfer not to have barriers (such as stupidly complicated publisher log in pages) in the way when it comes to accessing information.

This first example is about as good as it gets. A student uses Summon to locate an article (“Ethics, Public Policy, and Global Warming”)…

…when they click on the article link, Summon opens a new browser window and passes the OpenURL details for the article to the link resolver (360 Link). If the user isn’t already authenticated (e.g. by accessing Summon via the University Portal or via the VLE), they’ll need to log in. If they have already authenticated, then they don’t see this screen at all.

The login process logs the user into EZproxy, and also establishes an Athens session in the background (which isn’t required to access the article, but might be useful it they end up wandering off to look at other resources)…

…as this particular article is on JSTOR, the user is able to view the article straight away (via the “Page Scan” preview) or they can choose to download the PDF…

So, from Summon, there’s either a single click (if the user has already authenticated) or two clicks (if the user needs to log in) to get to the full-text (or a page that has a link to the PDF). Ignoring the ethical/moral/technical/philosophical issues of using a proxy solution instead of Shib, I think this is as good as it gets for students.

If they do have to authenticate, it’s a familiar login page and they’re not having to figure out which link on the publisher’s web site to use — do they try putting their university network login details into the username & password fields (1), do they scroll through a list of nearly 200 institutions (2) to find Huddersfield (and are we “University of Huddersfield” or “Huddersfield University”?) …or can they remember that the librarian told them to look for the “Athens” link (3) during the library induction all those months ago?

Plus, if they’ve found this article via Google Scholar, how do then even know if they have access to it? If you want to frustrate a student, nothing does it better than pointing them at a useful article that they can’t access ;-D

This doesn’t mean that there isn’t a role for Shib/Athens, but I feel it’s a different part of the jigsaw puzzle. If I’m an off-campus Huddersfield student wanting to get to ScienceDirect, there’s lots of ways to get there, but one of the simplest is to just Google “science direct huddersfield” (we don’t tell students about EZproxy, so they would never include that as a search term on Google)…

…where the first result takes them through to our electronic resources wiki page for ScienceDirect (which is where most of the other routes end up)…

…the first “Access Link” is the Athens link to ScienceDirect and the (slightly superfluous) note beneath is really just for students who’ve gone directly to ScienceDirect and who aren’t sure which of the various login options to select on the site.

7 thoughts on “EZproxy and Summon”

  1. Never, ever feel you need to apologize for stupid publisher login web pages. And as a librarian, I support wholeheartedly what you’re suggesting. Timely post this morning, actually had opportunity to reference it already once this morning.

  2. I think Nicole is right in a sense. Sure, it works great through Summon, and Summon is potentially a great option we should be providing to them, but users shouldn’t HAVE to use Summon, right?

    They should be able to search for things on Google too, and get to what they want — including getting access to library-purchased subscriptions for content when applicable.

    The problem is there are no obvious answers to HOW to make this ‘should’ happen. Same with Google Scholar — I agree with Nicole it’s unfortunate that users need to figure out how to set their preferences — but what other options are there?

    Yes, if they use Summon or another library-sponsored interface as a starting point, things work reasonably well.

    But it’s totally important that we figure out how to support users who chose to use other search interfaces as starting points too — some of these other search interfaces will undoubtedly work better for some users in some circumstances than ours. EZProxy doesn’t provide a very good solution there. Shibboleth comes a lot closer, at least it tries to address the problem, but it still has a ton of problems.

    With Google Scholar, having to set your institutional preferences is an unfortunate step, but is our current best answer to your question ” if they’ve found this article via Google Scholar, how do then even know if they have access to it?”, and works pretty decently once users figure out that step, if you get your link resolver set up appropriately.

  3. (And one important imrpovement in the Shib/Athens problems would be getting vendors to absolutely standardize their ‘login’ links to an easy to undestand interface. Athens has been a bit better at this than we in the US, at least.)

  4. PPS: If a vendor supports Shibboleth WAYFless login, then when the user is coming from a library interface like Summon, the exact same user login experience can be provided via Shibboleth as via EZProxy — but without having to maintain EZProxy in addition to Shibboleth infrastructure. Another downside of EZProxy is performance — it’s not great to have to proxy all traffic between a user and a platform through your EZProxy, which may introduce many more network hops. If the EZProxy login workflow is what you like (and I agree, although it only works when coming from library interfaces), you get the exact same thing with Shibboleth WAYFless login.

  5. Something that I use a lot to make it easy to get access to subscription material found via the web rather than the library is a bookmarklet that rewrites the URL of a journal page/subscription site page to the ezproxified version.

    This is something that does have “installation” and “training” issues, but then, isn’t infoskills development also part of the library remit?!

    OU Library ezproxy bookmarklet: http://library.open.ac.uk/services/lib20servs/libfxtoolbar/

    FWIW, here’s are a couple of tools to help create bookmarklet I created during my Arcadia time:
    http://arcadiamashups.blogspot.com/2009/10/get-current-url-bookmarklet-pattern.html
    http://arcadiamashups.blogspot.com/2009/10/get-selection-bookmarklet-pattern.html

  6. EzProxy is and always will be a massive hack, but in the use case of coming from a resource discovery service or linking page that supports it (Summon, SFX A-Z, database A-Z etc) it works really well. Shib has failed to take up in the US largely because of the popularity of ezproxy, even though it is indeed better at meeting the second use case of ‘external discovery’ as Dave explains above. However, its still not perfect at that due to its fragmented implementation.

    Right now, whereby each publisher can have a totally different approach and name for the Shib based login service (federated, institutional, shibboleth etc). It seems totally convoluted.
    If Shibboleth (specifically its UK Federation implementation) was given a brand, logo and set of UI guidelines for every publisher to sign up to and use, support and follow (how about EDU-ID?) then it could really take off. We have a service to replace Athens, but not yet the brand.

    In practice, we need to meet both use cases (internal discovery and external discovery) as seamlessly as possibly, so in Cambridge right now we are forced to run a painful combination of EzProxy and Shib.

    As Johnathan stated above and on his blog a while back, Shib WAYFless links could do the work of EzProxy, but we need more understanding of what is involved by all parties as well as agreements on the best way to perform WAYFLESS linking. Link Resolver support would help a lot.

    Another angle on the problem is that of IP range authentication and the concept of ‘on-campus’ access, which publishers seem to love and still force us to sign up to. Our Computer Service hate IP derived access generally, as the Cambridge domain cannot be generally well represented by a single range or even a regex.

    Given that we will shortly all be accessing resources on our always-connected i-Device Fondle-Slates (TM), how can we still be thinking in terms of ‘on-campus’ access? Logins, whatever route they follow, will have to become mandatory.

    I’d like to see some greater interaction from publishers on this. Librarians and their technical colleagues are pushing the boundaries, but ultimately publishers hold the cards in terms of what we can do to enable easy access to their expensive stuff.

Leave a Reply