Posts Tagged ‘ACM Digital Library’

The end of an authentication era: goodbye “AVAILABLE ON CAMPUS ONLY”

Posted on August 3rd, 2012 by Paul Stainthorp

For as long as I’ve worked in the Library at the University of Lincoln, a significant minority of electronic resources have only been available to use on library PCs, on campus. They allowed no Athens or other Portal login, and were authenticated solely by the IP addresses of the university’s computer network.

Like a red cross on the door of a plague victim, we marked these resources with the subtle message “AVAILABLE ON CAMPUS ONLY“. You might have noticed the bold, and the red, and the BOLD RED ALL CAPS!!!, just in case you were in any doubt about the awfulness.
Available On Campus Only
Fig 1. The horror… the horror…

Thanks to our new EZproxy service, the last of these messages has been consigned to the dustbin. All University of Lincoln library electronic resources are now available irrespective of your location*. On the odd occasion, off-campus access might still be a little bit more troublesome than on-campus, but we’re working hard to eradicate these differences next.

Here’s a selection of the e-resources that are newly accessible off campus for the first time:

The Portal and e-journals A-to-Z have been updated with access to these resources via EZproxy.

(Technical note: links from the University Portal to e-resources via EZproxy have a special format:…

…instead of:…

This allows EZproxy to inherit the authentication session of the Portal and pass the user straight through to the e-resource, without their having to log in again.)

EZproxy has also now totally replaced our previous, home-grown proxy tool, LibResProxy ( LibResProxy was a CGI proxy application which mimicked IP-based on-campus authentication. This service is no longer being used for access to any library resources, and it will shortly be switched off. So no more screens like this one:
Screenshot of LibResProxy

*Oh, all right: there’s always the odd awkward exception. There are a couple of streaming video services that, for licencing rather than technical reasons, are only available to view in the UK (BoB National) or in the Library itself (the BFI’s Screenonline). But let’s not allow them to spoil the moment.

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.

Finding full text in the ACM Digital Library core package

Posted on November 12th, 2010 by Paul Stainthorp

University of Lincoln students and staff have full-text access to the ACM (Association of Computing Machinery) Digital Library “core package” of around 50 ACM journals and magazines, but not to the full text of conference proceedings which also form part of the ACM Digital Library.

This can make it confusing to search the Digital Library: its search results don’t distinguish between material which is part of the core package and that which is not, and it’s not until you try clicking on a ‘Full text available’ link that you discover whether you will be granted access to a particular article.

The core package titles are listed on the Library’s e-journals website.

Screenshot of ACM Digital Library core package titles on the e-journals A-to-Z

What follows is a somewhat inelegant hack, but one which does provide a reasonably reliable way of limiting your search to only those articles which are available as part of the core package:

  1. Log in to the ACM Digital Library. (University of Lincoln students and staff: off-campus access is available via the University Portal.)
  2. Click on the ‘Advanced Search’ option, toward the top right of the screen.
    Screenshot of the ACM Digital Library
  3. Toward the bottom of the advanced search form, you should see a field labelled ‘Find ISBN/ISSN’. Copy and paste this list * of core package ISSNs (International Standard Serial Numbers) into the ‘Find ISBN/ISSN’ field.
    Screenshot of the ACM Digital Library
  4. Then, enter your search terms in the ‘Words or Phrases’ search boxes toward the top of the form, and hit ‘Search’.
    Screenshot of the ACM Digital Library
  5. You should see a list of search results, containing articles from only those publications which form part of the core package. All the articles in these search results should be available in full text to University of Lincoln students and staff.