E-journal authentication behind the mask

Posted on November 16th, 2011 by Paul Stainthorp

This blog post is an attempt to elaborate on a problem with managing on/off campus access to electronic journals at the University of Lincoln. It’s a problem which confuses a lot of our users. I hinted at the issue in an earlier blog post.

Underlying the problem is a lack of consistency in the way e-journal platform providers/publishers implement Athens/”Shibboleth” access to their content.

I think the answer to this problem is “…use EZProxy as well or instead“. (We plan to do so.) However if anyone from a ‘strong’ federated-access position can suggest a way around the problem based purely on honest, SAML-based principles, then I’m all ears!

~~~wavy lines~~~

The system we use to manage access to e-journals at the University of Lincoln is EBSCO’s electronic journals A-to-Z. Within its underlying journals knowledgebase, the A-to-Z stores a URL for each journal – here I’ll refer to that URL as A.

The A-to-Z also provides the facility—a very nice facility, as it happens—to rewrite that URL according to a set of predictable rules, generating a new URL which is a function of the original URL: in my pseudomathematical shorthand I’ll call this f(A).

EBSCO call this facility of theirs a “Proxy Server”. Now – I could be being thick, but I don’t think this is a proxy server: it’s a URL rewriting application which merely happens to be used by some libraries to redirect traffic via a URL-rewriting proxy (such as the aforementioned EZProxy); in fact it can be used to ‘mask’ any URL.

We use the so-called “Proxy Server” facility to mask the default URL, A, and instead direct the browser back to the OpenAthens authentication point for the journal provider/publisher (allowing authentication both via the UK Federation and trad. Athens), with a redirect back to the post-authentication page for the journal. We’ll call that page A′ (i.e. “A prime”). A′ permits access to the full text of the journal.

Flowchart of URL masking and authentication workflow

N.B. it’s only possible to do this at all if the Athens/UKAMF authentication point for the journal has a predictable structure. If A′ includes any randomly-generated or unknown elements that aren’t in A and which vary from journal to journal, then A′ can’t be generated by f(A) – so some providers rule themselves out at the first hurdle. Bonjour, most legal databases! Yeah, you know who you are…

If it isn’t possible to create an A-to-Z “Proxy Server” URL mask, then our usual fallback position is to rely on IP authentication for on-campus traffic, but to instruct the user to manually select an Athens/’my institution’-type login for off campus access. This is not ideal: it confuses off-campus users who are used to seamless on-campus access, and it requires that we create help guides—I name and shame thee, Elsevier ScienceDirect—to lead people through often terribly confusing login procedures.

Flowchart of authentication workflow with on- and off-campus differences

There’s another complication: some journal providers, upon Athens-esque authentication from A, don’t send the user to A′. Instead, they redirect to a generic post-authentication page, D.

This = Bad. If you do this, I… just… can’t speak to you right now.

If we don’t (or can’t) apply a URL-rewriting mask in the A-to-Z for a journal package which exhibits this awful behaviour, then we’re relegating off-campus users to a third-class service; further widening the gap between on- and off-campus behaviour. If we do apply a mask, we relegate all users to the same lack of functionality. Which compromise do we choose? We’re damaging the user experience in both cases. [Click the diagram below to embiggen.]

Flowchart of complex authentication workflow for masked and non-masked journals

Finally, and for the sake of completeness, I think that this [below] would be the equivalent flowchart for EZProxy. (You can see why some libraries—and apparently their users—find it attractively simple. It also has the advantage that the ’masking’ is consistent across all or most journals, the configuration for each e-journal provider being done within EZProxy itself.)

Flowchart of the authentication workflow using EZProxy

Last word – here’s a useful page from Eduserv of Athens-authentication deep links for various e-resource providers. It may be helpful in creating masked URLs for Athens-authenticated journals.

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

4 Responses to “E-journal authentication behind the mask”

  1. Addendum: I received these comments (by email) from the main strategic developer of the A-to-Z at EBSCO. I hope he won’t mind me reproducing them here!

    If you haven’t already, please look at the NISO Espresso initiative’s
    recommended practice ( http://www.niso.org/workrooms/sso ). This
    initiatives includes recommendations about how a content provider should
    support authentication for deep linking and in particular it is
    counseling consistency (see section 4.4.3 for recommendations). As you
    point out, too often the link to an article via Athens bears almost no
    relation to the link to that same article if one were to IP authenticate
    and that is something that Espresso is trying to address.

    PS. We do call our A-to-Z feature the “Proxy Server” — but it is really
    a URL-rewriting template to support the library’s Proxy Server, and as
    Paul points out it is very useful for modifying URLs even if no proxy is
    involved– some customers add un/pw to links (only for secure A-to-Z
    lists please); others use to designate “profiles” or authentication
    types (e.g. you could apply the following template to an EBSCOhost URL
    “{URL}&authtype=IP,Shib” to force IP authentication first, then Shibboleth second.

  2. I have some ideas of how you could improve the user experience, but whether they are practical, affordable and sustainable I’m not sure. They certainly fall into the category of ‘work arounds’ not ‘solutions’

    While the URL re-writing is a nice way of bridging the gap when it works, it isn’t particularly sophisticated. By utilising scripting tools you could do more to avoid bad user experiences. In the second example where you have the potential of a tortuous vendor login (‘Click Athens’, ‘Click Alternative Login’, ‘Choose University of Lincoln from the list’ blah blah) you may well be able automate this behind the scenes using a scripting library like ‘Mechanize’ (for Perl or Ruby – other languages have equivalents) which allow you to emulate browser/user behaviour in a script.

    So in this case the A-Z list could direct to a local script (with the original URL as a parameter). The local script could navigate through the multiple screens and then send the user to the correct URL once it has found out what the ‘destination’ would be – whether this is the login screen, or (if you make the script handle the login as well) the final destination URL they were looking for.

    This approach might also help with the ‘generic post-authentication page’ issue – as long as once the user is logged in, the original URL (A) can be accessed directly and not require additional steps.

    This is not necessarily a trivial undertaking – each provider would require a different set of code to navigate their particular interface, and you may find spanners are thrown in the works by javascript, cookies, security certificates and other vagueries – some of which can be worked round, and some not.

    However, this work could be shared across a large community I guess – the ‘route’ through Elsevier’s login screens would be very similar no matter which UK institution you were from I guess. So the level of effort needed across the community may not be unsustainable.

    The Open University do some simplified form of this when linking from their VLE (Moodle) to certain online sources to help ensure students get directly to the full text, and not intervening pages where they have to click something or other – although they deal only with some very simple scenarios (specifically Swets from memory)

    I also think there is some possibility of putting this type of functionality into Link Resolvers – the Link Resolver provides a ‘point of intervention’ for the library when getting the user to the resource and so offers a point at which this type of script could kick-off. Again – this would offer a ‘community’ level approach to the problem.

    As I said at the start – I don’t know how practical/sustainable this type of approach is, but a project to try it out might be supported by a JISC Rapid Innovation call – such as http://infteam.jiscinvolve.org/wp/2011/11/16/oerripreview/

  3. Another option I keep kicking around is a browser plugin/extension that would offer lots of ‘helper’ functions. This could offer a range of functionality – perhaps bringing together existing functionality from other extensions like LibX (http://libx.org/) and DiscoJuice (http://discojuice.org/browserextensions).

    Even where nothing else could be managed a browser extension like this could keep a record of the original URL you were trying to get to, and once the user was at ‘D’ they could be prompted by the extension to go to the original URL.

    The disadvantage of a browser extension is of course that the user has to install it (and when I’ve looked at these in the past, several libraries have told me they wouldn’t be allowed to install an extension on the PCs they provide for students in the library). On the otherhand – a ‘scholars plugin’ might gain traction, and perhaps is not so far away from other specialist software like reference managers that we expect staff and students to at least consider. (and if such a plugin integrated with Zotero, it would be quite a compelling offering I think)

  4. Philip Adams says:

    The next version of OpenAthens LA (Local Authentication), out later this year/beginning of next, includes an integrated proxy.

    http://blog.eduserv.org.uk/2011/03/28/openathens-la-2-2-integrated-proxy/

    This may make it easier to configure access to otherwise difficult to access electronic journals. We are looking forward to exploring this possibility when the release comes out. We might need a machine with more space and memory, though, if it it to act as a proxy service as well as doing the authentication.

Leave a Reply