The joy of e-resource authentication (warning: may contain sarcasm, hyperbole, and self-indulgent whining)

Posted on May 18th, 2011 by Paul Stainthorp

(Alternative title: why I’m going bald.)

Managing the authentication of university students and staff to electronic library resources is an awful, awful pain and I wish it would all just disappear. There, I’ve said it.

My line manager (Deputy Librarian: Academic & Technical Services, Lys Ann Reiners) is very keen for me to involve as many Library staff as possible in managing our authentication régime. For most aspects of my job, I’m more than happy to spread the love around (I don’t agree with keeping knowledge—or extra work—to myself), but when it comes to authentication, I feel guilty even asking my colleagues for help, in case I expose them to some kind of toxic authentication ju-ju death rays.

I realise that I can’t shy away from explaining things merely because they’re confusing and depressing. We can only make sense of authentication for our users once I’ve stopped putting my fingers in my ears and hoping it’ll all just go away. We have already made a start on documenting the mess, but it was these [Nicole Harris] two [Dave Pattern] recent blog posts which have spurred me into writing this, in the spirit of catharsis:

Authentication to e-resources at the University of Lincoln

A trilogy. A tragedy. A travesty.

1. IP authentication (for on-campus users)

  • Some (but not all) of the 150+ e-resource publishers/providers with which we have a relationship have the University’s IP ranges on file. This allows people using on-campus computers to seamlessly access restricted content (e.g. full text) from those providers’ sites.
  • But we have no real procedure for keeping those IP ranges up to date – i.e., of informing providers of any changes. I’ve asked my colleague (Library (E-resources) AssistantElif Varol to do something about this.
  • In particular, we now have single ‘apparent’ external IP addresses associated 1:1 with each University building. This should mean we can [a] simplify the information we give to providers, and [b] associate usage with particular buildings.
  • So far, so simple. But the fact that on-campus authentication is so seamless (as far as our users are concerned – they needn’t even know it’s there!) does cause a problem when those same users try and access the same resource from off campus and don’t get the same seamless access.
  • Also, University ICT services occasionally look worried when I tell them about IP authentication. They just aren’t comfortable that I pass on details of our IP ranges to third parties.
  • For resources where only IP-based authentication is available, in order to provide off-campus access we make use of a CGIProxy-based application which we call ‘LibResProxy’ (see part 3, below), with mixed success.

2. [Open]Athens and “Shibboleth” (but not really)

Deep breath:

  • We are members of the UK Access Management Federation. Our nominated, outsourced Identity Provider (IdP) is Eduserv, to whom we pay an annual subscription. This means we can use their product, OpenAthens (often just referred to as “Athens”), to provide local authentication (via University Portal login using network\accountID) to both ‘traditional’ Athens-protected resources and to resources which have abandoned Athens in favour of true federated access (which lots of people refer to as “Shibboleth“, even though that’s not really the correct terminology). The Eduserv software we’re running on the Portal is called ‘AthensDA'; we probably ought to upgrade this to a newer version called ‘OpenAthensLA 2.0‘, but we haven’t really discussed it yet.
  • As far as the user is concerned, this means we can create a link to an e-resource which will work both on- and off-campus. These URLs are generally in the form:, where the first part of the URL sets an Athens ‘preferred organisation’ cookie, associating the user’s computer with the University of Lincoln, and “XXXXXXX” is the percent-encoded URL of either: [a] the defined Athens authentication point for resources that use the ‘old’, traditional Athens protocol (these have to be activated first—”cascaded to permission sets” in Eduserv terminology—by an administrator); or [b] a WAYFless URL for a resource which uses the ‘new’ federated access. The format of this last category of WAYFless URLs are unpredictable and very difficult to build, and for some resources can’t be created at all, leaving the user with no choice but to navigate a horrible “Where Are You From?” form where they have to select their institution from a list before they’re allowed to log in.
  • What the user sees when they click on this link is a blue-and-orange login page with a link to ‘Go to the University of Lincoln login page »‘. Clicking on that link displays a pop-up http login box (unless they are on campus using IE, in which case they’re logged in automatically), in which the user must enter some variation of network\accountID and their University network password. This is highly variable, depending on the user’s operating system and browser.
    Screenshot of the OpenAthens login point
  • This is fine for situations where we can control exactly where the user is going and what links they are clicking on, and where we have a chance to set the Athens cookie: this happy state of affairs applies to the University Portal, and almost nowhere else; certainly not to the open web and users coming via Google Scholar.
  • Problems: and they are legion:
    1. We’ve not been systematic about migrating resources from the ‘old’ Athens login to the ‘new’ federated access. (We deliberately didn’t want to stop using ‘old’ Athens links to resources if they were working. If it ain’t broke…) For the user, there’s no difference between the two, hence the lack of urgency – for the Library, it’s become rather confused and difficult to manage.
    2. If, for whatever reason, the user doesn’t end up with (or loses) the Athens cookie which sets their preferred organisation, then they don’t see the link to ‘Go to the University of Lincoln login page »‘, and instead have to follow the rigmarole of setting their preferred institution again. Needless to say, most students and staff are entirely mystified by this arcane process.
    3. Related to point 2: a students or member of staff who has a relationship with more than one UK institution (e.g. two universities/colleges, or a university and the NHS) tend to run into problems, because you can’t easily have two Athens ‘preferred organisation’ cookies set at the same time on the same machine. I know, I know: it doesn’t sound very “federated”, does it?
    4. Sometimes… it …Just. Doesn’t. Work. (Because of pop-up blockers, trusted sites, peculiarities of various versions of Windows, bugs in Google Chrome, leaves on the line, etc.) When this happens—when we can’t solve the problem—and when the user is getting very frustrated, I have to grit my teeth and generate a separate, “classic” hum————— Athens username and password for that user. This gets around the access problem in the short term, but tends only to increase confusion in the longer term.
    5. Finally, and most frustratingly: all of this is completely blown out of the water if the user encounters a resource (a journal article, say) on the open web: via Google, or even via our own Electronic Journals A-to-Z. They don’t automatically see the OpenAthens login point, so they have to hunt down a link to “login to Athens here” (or similar). Each provider deals with this differently, so a user can’t necessarily apply what they’ve learnt from one resource to any other. Some providers (‘SPs’ in access-speak) allow libraries to construct complex ‘masked’ deep-linking authentication URLs. These make it easier for us to automate the login process from the A-to-Z to an individual journal. Others just don’t work that way – so we write help guides instead. Eduserv have a web page about creating deep links for authentication.
  • If you’re not utterly, hopelessly confused by all of the above, then I bow down to your machine-like intelligence.

3. The grab-bag approach: everything else

  • For e-resources that don’t work with OpenAthens, we have a number of tricks of last resort. Some of these tricks have been built for us by Tim Simmonds of the Online Services Team (ICT). When they work, they’re brilliant. But we have no control over whether they’ll work or not with a particular resource. They tend to use the Portal-esque network\accountID and password as login, which is at least consistent with OpenAthens.
  • This includes our form capture tool, which we use to create ‘faked’ URLs for resources that have their own username and password (in effect, it pastes the login details into an HTML login form on the user’s behalf and hides the authentication from public view). The popular business database Factiva works like this.
  • It also includes LibResProxy, which provides off-campus access to certain (IP-authenticated) library e-resources. We fall back on it where no other method of off-campus authentication exists. It’s a bit hit-and-miss whether it will work with any given website, depending greatly on how the site is constructed and particularly on how heavily the site makes use of scripts (e..g JavaScript) rather than ‘vanilla’ HTML: for instance, it’s fine with the ACM Digital Library, but spits its dummy out over the IEEE Computer Society Digital Library.
  • Last of all – if all else fails, we give a username and password out to the student and tell them to get on with it. We change these passwords once a year as a security measure.

4. Whatchagonnadoaboutit?

We can’t go on living like this. In a future blog post, I’m going to map out a possible way forward for authentication. It’ll probably involve thinking about some of the plans my colleagues in ICT have for single-sign on and OAuth, and what those plans mean in a library context.

Tags: , , , , , , , , , , , , , , , , , , , , , , , ,

13 Responses to “The joy of e-resource authentication (warning: may contain sarcasm, hyperbole, and self-indulgent whining)”

  1. Profile photo of Joss Winn Joss Winn says:

    You’ve been bottling that up, haven’t you? I bow down to your machine-like ability to pump out blog posts ;-)

  2. Mark Brown says:

    Excellent post – what really gets my goat going is that there seems to be a little national cross-over between e-resource librarians – who struggle with this stuff daily- and our institutional IT departments. Every student who comes to us not only has to pay inflated fees, but has to struggle with arcane and different levels of authentication at every institution. It does not improve the student experience and it actively impedes learning.

    Why pay publisher deals of 000,000K when we cant even get this stuff working, maybe we need a national site somewhere where students can just post how rubbish their experience of logging onto our eresources by insititution, a league-table of awfulness . Like a LoginAdvisor, to match TripAdvisor. If publishers were rated like hotels, they soon take notice :-)

    Yes. Grrr.. (and relax)

  3. sue watling says:

    You mean it’s not just me – it really is a confusing and un-intuitive system???
    Seriously though, great blog post Paul, and now I’m researching again and the OU have finally worked out I’ve finished my course, I’m really struggling with the electronic journals at Lincoln – it’s nearly all done from home and is sooooo hard. If the university is serious about research – Student as Producer – postgraduate provision etc – it has to invest in a research infrastructure. The OU electronic journal system was so user-friendly – if only we could have something similar.

  4. @Joss – :-P

    @Mark – good point. My colleagues in ICT here at Lincoln are aware of some of the problems, but it’s certainly never been for them the high-priority headache it is for the Library. That’s changing, though. I like the idea of a provider-authentication wall of karma. I suspect that students wouldn’t be motivated enough (or understand who’s at fault) to post to it, but librarians? Hmmmmmm…

    @Sue – no, it’s not a great system, but Lincoln isn’t particularly bad as universities go (we have a few broken bits we do need to fix asap, but most of these problems are common to all UKHE libraries). I’d love to know what the OU are doing right! Might tweet @OU_Library and ask them. I know I’ve painted a terrible picture here, but a lot of these problems really only affect the Library staff directly – we try and hide quite a lot of the inconsistencies from students/staff. I’d love to sit down with you and try and fix some of the problems you’ve been having… this blog post might help.

  5. I know you like to build your own, but buying EZproxy off the shelf really is a straightforward option. You can specify when it needs to re-write Javascript links rather than just HTML links, for example. It is very rare that we can’t configure an IP-authenticated tresource o work with EZproxy for off-campus access.

  6. Niki Rogers says:

    Great post Paul you actually explain how things work (ornot as the case might be) for us very well and maybe this is what is needed to move the library forward
    I am glad though that someone can explain in relitively basic terms the problems we are having with authentification etc well done – keep them coming

  7. Julian says:

    Thanks for the little bit of red text at the end of section 2. Most reassuring, as I began to feel clouds forming in my mind round about paragraph 3.

  8. Dave Pattern says:

    Just to echo Terry’s wise words — apart from a couple of e-book supplier platforms, with Summon we push everything else that requires authentication through EZproxy and, quite simply, it works. I honestly can’t remember the last time I handled a student complaint or problem report that turned out to be to do with authentication.

    Another huge plus is that you can great some great usage stats out of the software — even tho we don’t need to, we push on-campus users through EZproxy, just so we can use the stats to get a fuller picture of e-resource usage.

    Hand on heart, EZproxy has easily been the best $500 we’ve ever spent (no idea what OCLC are currently charging for it tho). I just wish other, considerably more expensive, software worked half as well! :-D

  9. Dare I say it, but the easiest way to solve the login problem is to cut out the library altogether and sell direct to the user – aargh! The simple elegance of the deepdyve platform with its ‘login via facebook’ button is probably about the best user experience you can get. I’m obviously not condoning cutting out the library (before the hit squads come to get me!) but its worth highlighting that the institutional subscription model is the thing that causes the problem. The experiments around direct-to-consumer academic publishing are fascinating though.

    I think the main problem is highlighted well here – we have no carrots or sticks with the publishers and it is getting increasingly hard to persuade them to do anything at the moment as the focus is totally on price in a time of shrinking budgets. I don’t even think a tripadvisor ‘your site sucks’ type approach would make any difference as institutions will buy the resources anyway.

    Im setting up a working group under the auspices of REFEDS ( to produce a simple guide for publishers and then to act as a lobbying group to get them to use the ‘embedded discovery’ approach which makes a lot of this go away. If anyone is willing to join in and help out, I’d be extremely appreciative!

  10. Interesting… are the two authentication models mutually exclusive?

    How about:

    [1] User authenticates via institutional login to a Facebook/Twitter app, which associates their institutional credentials with their fb/tw account.

    [2] User can then log in to any publisher’s site via a familiar “log in using Facebook” / “…Twitter”, and access content from institutional subscriptions.


  11. It’s possible Paul, but creates a whole bunch of issues regarding provisioning / deprovisioning. You can have a situation where the service simply maintains static information about that linkage – which works fine until the account is deprovisioned by the institution but the static association remains and student gets access to lots of lovely goodies way after they have left via a facebook login. This is fine for low risk services and it’s the sort of thing done by, but I can’t see it working well for academic publishers.

    Alternatively you have to do some dynamic checking everytime the user logs in with their facebook account to make sure that the associated institutional account is still valid. In a username and password scenario, this pretty much means having to get the user to login again so defeats the purpose.

    There have been some developments looking at account linking that try to work around that problem but nothing that yet delivers on both security and user experience. Many put the account linking in the hands of the user which is fine, but is again another headache and something that has to be actively managed – and people aren’t interested in actively managing their identities separately from point of interaction as microsoft are beginning to learn :-) It’s something we continue to track though, someone will crack it at somepoint, hopefully soon. I imagine it will have an OAuthy type feel to it when it does.

  12. Andy Powell says:

    Totally agree with you about OAuth being a possible way forward.

    FWIW, the next version of OpenAthens LA (due out autumn 2011 I think) will have a built in proxy module, which will make management of federated and proxied resources somewhat easier – at least as I understand it.

  13. Thanks Andy (and all) for your comments.

    @Andy: I’ll look forward to hearing about the next version of OpenAthens LA. We never did make the leap from AthensDA to LA 2.0; it’s been on my “oh yeah I should probably do something about that” list for a while. Now I can postpone thinking about it a bit longer…

    @Nicole: yes, I can see that it’s not as simpe/istic as I’d like it to be :-)