Research database access friction Why is access to research databases (ebrary, EBSCO, JSTOR, LexisNexis, Project MUSE, Proquest, Sage, Science Direct, etc) – even when you’re a student or faculty member at an institution with a subscription - such a hassle, especially when off-campus or on a phone/tablet? Is there any way to solve this?

I’m also curious which database is least painful to deal with, and what a solution to this problem could be.  Who would be best positioned to fix this problem?  How should they fix it?
The fundamental reason for friction is that these are commercially licensed resources, and so the licensors have a strong motive to ensure that only people who've paid for it in some way have access to them. Without that requirement, there'd be no reason to throw up the barriers.

The exact ways in which this friction manifests vary a lot - my understanding is that different access methods can be preferred in different places. I'll try and be general here, and explain what's currently used.

There are two basic methods for authorisation.


Site verification.
Individual verification.


The first of these involves identifying that you, the user, are coming from a site which has access. This is pretty trivial if you are on-campus and that campus has a defined IP range - "oh, they're coming from 1.2.3.4, they must be at Wherever University, let them in". In these cases, it can be completely seamless - in fact, so seamless that one real problem is that users can believe the resources are public, and get frustrated when they go home and they're not there! It also allows for 'walk-in' access - many licenses explicitly provide that if you're physically using the library, even as a visitor, you can access these databases. I am guessing from your post that you normally use this approach.

The second, individual verification, relies on each user having a signin to the database. This can be an enormous headache for both institutions and users, especially when you have multiple systems you need to sign in to. IP authentication is thus more popular.

However, IP verification breaks down if your institution shares its IP ranges with someone else (this is more common outside the West). If two institutions have a shared IP range, there's no practical way to provide access to users from one but block them from the other. If most of a country shares an IP range... you can see where this is going. 

A similar problem arises if you are at an institution that uses IP authentication and you go somewhere else - perhaps you're at a conference, perhaps you're working from home, but either way you're not on the right network. One approach to get around this is to provide a VPN system, which drives all your traffic back through the "right" IPs. This is a hassle for users (and for the provider), and may not always be available. Another approach is to use a proxy server, but this is again something of a hassle for users. Both can lead to long network delays, and you have the associated problems of actually getting into the VPN/proxy server.

A common approach is to fall back on individual authentication. Most major databases offer optional individual logins, which let you save papers, set your viewing preferences, etc. These can be repurposed as logins which 'remember' that you have access rights, and let you use the service when away from your home network. They'll usually stop providing access after a while (a few weeks or months?) if you haven't signed in to it from your home network at some point, in order to prevent them remaining active forever. However, this still has the too-many-names problem of individual verification - no-one wants to juggle a ScienceDirect account and a JSTOR account and a Lexis account etc etc etc. 

The best solution to this is to use an identity management/single sign-on system. The most common of these at the moment (less common in the US, I believe) is Shibboleth. Shibboleth provides a single login screen for all participating services. A user selects their home institution, is taken to a page there, signs in (or is automatically authenticated), and returns to the database service with authorised access. If done effectively, this can even completely replace IP authentication - you can do the necessary authentication for people on a local network automatically.

In theory, a system like Shibboleth should reduce friction dramatically - it can provide a standard sign-on system for all databases, and only require a single username/password which the user already knows (usually because it gets them into their email...). Compare to, eg, the ubiquitous "sign in with Facebook/Twitter/Google" buttons on web services. However, the problem is that each individual provider service has to set it up. The big databases like ScienceDirect or JSTOR are usually happy to do this, but small journals or databases - especially if the majority of their customers are happy with IP authentication - may not be willing to go to the effort of setting it up.

In an ideal world, we'd all be standardising on something like this. Unfortunately, there's a lot of people who all have to pull in the same direction for it to happen, and what is most convenient for publishers is not always what's most convenient for libraries or for users.