Authentication methods

Other the last ten years or so, there have been free main ways of providing access to resources which we subscribe to.

• IP authentication. The resource checks the IP address of your computer, and it if falls within a known range for Sussex (or for that matter  any University subscribing to it). This was fine in the very early days when accessing content online was still quite novel. But soon, understandably, people wanted (and needed) to access things from where ever they may be. This is where ezproxy comes in, it legitimately fools the resource we subscribe to in to seeing  those who use it as coming from our campus IP range. IP authentication is simple, which has its pros and cons.
• Another popular authentication system was Athens. It was developed in the UK, and while some other countries used it, it was heavily associated with UK Universities. Those who have been here for a few years (and with good memories) may recall being allocated an Athens username and password. You can read more about it on the Eduserv (a non-profit in Bath) website. In the summer of 2003 we were one of the first to adopt a new version of Athens which no longer required a special username and password.  Athens Devolved  Authentication used Sussex’s sign-on systems to authorise users. We set up a system which authenticated users for both AthensDA and ezproxy at the same time, so that you would only ever need to enter your username and password once in a session, no matter how many resources you visited. We even wrote an article about it.
• Around 2006/07, a new international authentication system was gaining momentum. It was called Shibboleth and was part of the large Internet2 programme. Athens was centrally funded by JISC (an HE funding and services providers), however they decided they would stop the funding in the summer 2008. Many Universities, including Sussex,  moved to using Shibboleth at this time.

End User Experience

In short, the user will go to a online resource’s website where at some point they will need to authenticate. The first step, when using Shibboleth, is to say where you are from (what organisation is providing you access to this). How this is done varies by resource, but normally a drop down box of institutions.

Once you have selected, in our case University of Sussex, you will be redirected to an authentication page on a Sussex server.  Your password is only ever entered in to a Sussex server. If your credentials are ok, you will be redirected back to the resource, but now with access to all the areas our subscription permits.

How it works

Shibboleth is built around Federations. Federations are made up of Universities and subscription based online resources.

• IdP – Identity provider. Often a University or college. It can vouch for, and confirm the identity of people, and (optionally) state they are a member of that institution.
• SP – Server  Provider. A resource on the web which protects some/all of its content, a user will need to be authenticated for by a IdP to gain access.

Federations are often country based, in the UK we have the ‘UK Access Management Federation for Education and Research‘, normally referred to as the UK Federation. Organisations can join the Federation, as a IdP, a SP or both (example of the latter: a University which authenticates its students and staff, but also has part of it’s website which is protected by Shibboleth, such as a journal run by School). In doing do the organisation agrees to abide by the terms of the federation.

While there are several options, and especially third part outsource options, to keep it simple, organisations will then install the Shibboleth server software, and configure it, in the case of an IdP, to authenticate against their University system (which is LDAP based for Sussex).

WAYF

The ‘Where Are You From’ (WAYF) service is a key part of Shibboleth. When a user needs to be authenticated using Shibboleth from a resource’s website, the user needs to be directed to their University Shibboleth authentication page, and to do this, it needs to do which University. The WAYF server, simply provides a list/search of all organisations which are IdPs in the Federation, and then direct the user to the appropriate site.

Some international resources require you to first select your country (actually your Federation) and then your institution (from a list of those in the Federation). While there is a central WAYF website maintained by the UK Federation, resources are free to build their own, using data shared between Federation members (an example of both of these is ScienceDirect).

This isn’t a perfect user experience, and takes more clicks than one would like, but hopefully is something that can be refined in the future.

More information

SWITCH, the Federation for Swiss Universities, has a good explanation of how Shibboleth works, of course Wikipedia also provides a general overview.

It’s a fairly simple web application which we run on campus, supplied for many years by a great one man company called Simple Solutions and now owned by OCLC (a large Library IT company in the States).

As the name suggests, it is a proxy. Though unlike a more traditional web proxy, such as Squid, the proxying is done via a URL which refers to the proxy directly, rather than via browser or network configuration.

In a nutshell: stick http://ezproxy.sussex.ac.uk/login?url= in front of a URL and your web request will go via the ezproxy server. If the website in question has been added to the ezproxy configuration then it will proxy the website, after authentication.

• It will only proxy sites we’ve explicitly added, to avoid misuse. However online services are constantly changing their domain and hostnames (or using other domains behind the scenes to serve images, javascript, PDFs etc), which means we are constantly adding to this list.
• If you are not already authenticated, it will redirect you to a standard ITS login page on the main Sussex website. Once authorised it will take you back to ezproxy.
• Ezproxy is setup to use wildcard DNS, each host/domain it proxies is a virtual hostname. This makes the URLs readable and keeps things simple. Example: http://www.sciencedirect.com.ezproxy.sussex.ac.uk/science/journal/0264410X
  Notice this is the normal URL but with “.ezproxy.sussex.ac.uk” added to the end of the hostname.

Knowing this can be useful. Imagine you follow a link – while off campus – to a journal article, but you can’t access it because it does not recognise you as a subscriber. By adding the prefix “http://ezproxy.sussex.ac.uk/login?url=” to the front of the URL it will mean you can access the article if we subscribe to it.

While Ezproxy – and IP authentication – can seem a little simplistic. They do tend to work well with relatively few problems.

A new alternative to IP authentication is Shibboleth, a federated authentication system..

A DOI has two parts, the first part of the code identifies the publisher, the second part, after a slash (/) identifies the article/item from the publisher.

DOIs are quoted with ‘doi:’ proceeding the number.

Far more useful though is that you can proceed the doi with http://dx.doi.org/ to create a link which will take you to the article.

Some examples:

• doi:10.1016/j.vaccine.2009.07.034
• DOI: 10.1080/00908320903077001
• DOI: 10.1111/j.1468-0092.2009.00325.x

Notice that most journal websites provide the article’s DOI somewhere on the page, though this is not consistent. This can be a pain when trying to explain to someone how they can reliable find a DOI. The other option is to use the lookup function on the Crossref website.

DOIs are useful, and a great way to refer to an article in a unique, consistent and permanent way. They do however have a couple of drawbacks from my point of view.

First, they will take you to the official publisher copy of the article. Why’s that a problem? Well we may have access to an article via a third-party website or other means, but not via the publisher directly. An academic links to the DOI of an article they wish their students to read, and of course the students have no access to the fulltext because they are taken to the publisher website. This is where a link resolver can be handy.

The second issue is that the link will not use a ‘proxy’ for allowing people to access the full text as if they were on campus. Again, a Link resolver is useful as it can be configured to add the URL of the proxy server on to the front of the article URL. The introduction of Shibboleth (an alternative way to authenticate) may make this less of an issue (i.e. you can go to the website, and then authenticate once on the site using your Sussex credentials).

You can of course create a URL which uses the proxy and the DOI. For example:
http://epzroxy.sussex.ac.uk/login?url=http://dx.doi.org/10.1111/j.1468-0092.2009.00325.x

In a nutshell, A Link Resolver takes a reference/citation for a journal article (or any item), and provides various ways to access it.

The common scenario is:

• A user finds a record/reference for a item on a journal article indexing service, such as Google Scholar, Web of Knowledge or Scopus
• The service’s website has a link to the Link Resolver (for Sussex called ‘Find it @ Sussex’) next to the the reference. The link includes parameters about the article including its title, ISSN, the year/volume/issue of publication and page numbers.
• When the user follows the link, The Link Resolver will then show a webpage, which shows a link to an online version of the article, if we subscribe to one, and alternative means of accessing it as well.

How does this work?

The source website

First things first, the link has to appear on the original website (Web of Science, Scopus, etc). This isn’t black magic. These sites have agreed to provide a link to a Link Resolver (which in turn makes their website more useful).

The parameters are the same no matter which Link Resolver is being linked to, because it is an open standard (OpenURL), just the hostname changes. For Sussex it is http://sfx.lib.sussex.ac.uk:3210/sfxlcl3/

These sites know which Link Resolver to provide a link to as they know who is providing a user’s access (because they are subscription based). We provide details about our Link Resolve, its URL and name, when we subscribe to these resources.

The link itself takes the form of a base url (eg http://sfx.lib.sussex.ac.uk:3210/sfxlcl/) and then a list of parameters as defined by the OpenURL standard.

An example OpenURL:

http://sfx.lib.sussex.ac.uk:3210/sfxlcl3?sid=google&auinit=H&aulast=Jin&atitle=Toxicological+evaluation+of+live+attenuated,+cold-adapted+H5N1+vaccines+in+ferrets&title=Vaccine&date=2007&issn=0264-410X

Which is a link for: Toxicological evaluation of live attenuated, cold-adapted H5N1 vaccines in ferret. Vaccine [0264-410X] Vol 25 (52) 2007 pp 8664-8672

The Link Resolver

So a user clicking the link will create a HTTP GET request to the Link Resolver, passing parameters about the article in question. How the Link Resolver works internally will vary on the software, but basically it will use rules and a knowledgebase to decide (a) if we have access to the journal for that year (b) the URL the user needs to access the full text.

How does a Link Resolver know what we have access to (and from which site)

Link Resolvers will use a database consisting of thousands of journals. The knowledgebase is broken down by ‘providers’ (vendors) which are normally publishers. Within providers are ‘packages’, bundles of journals with certain coverage dates. These mirror the packages publishers typically make available to Libraries and Universities to subscribe to.

Example:

• Let us say we subscribe to the ‘Social Sciences’ package with a particular Publisher, which provides access to a collection of journals for volumes after 2001.
• This contains a journal ‘Economics Today’.
• Hopefully the knowledgebase will contain details of such a package, and we can flag we have access to it.
• A user finds an article on Web of Knowledge from ‘Economics Today’, published in 2005. They follow the ‘Find it @ Sussex‘ link which takes them to the Link Resolver.
• The link contains details about the article (journal, year, issue, etc) and the Link Resolver knows we have access to it, because it knows the journal (and volume) are in the package above, which we have flagged we have access to.

The final stage is making a link to the full text of the article. This is normally done following some rules for each publisher and package. For our example (fictional)  publisher package, the url may take the form: http://journals.publisher.com/$ISSN/$year/$pageNumber.
So the Link Resolver, knowing this format, can construct a URL with the information it has about the article.

More than just the full text

A Link Resolver can do more than just link to the full text, especially if we don’t have access to it! It has the details of the journal you want, so it can do quite a few things with this, such as provide an import file for Reference Management software such as Endnote, or offer to search other catalogues and websites with the details. Potentially Link Resolvers could work with much more than just journal articles, they have started to add (e)books to their knowledgebase and could really act as the middleman for any type of document.

Providing a website to search and browse for journal titles

If you think about it, the knowledgebase will have details of all the journals we have access to, and the coverage dates. So as an offshoot, the same system provides the web interface to our online journals search/browse section of the Electronic Library. Using the data we maintain here.

One of the useful things about Link Resolvers is that they can help avoid broken URLs (something quite annoyingly common with publisher websites) and journals changing between different suppliers. So long as a link goes to the Link Resolver, it will continue to work unlike one which goes straight to a article which could break.

So, keep a look out for those Find it @ Sussex Buttons.

And if you’re interested, have a look at the OpenURL specification (version 0.1 is much easier to understand than version 1.0!).

There are those who complain everything is too complicated (they are probably right), and those who would find alternative ways of doing things (even if it takes a bit of setting up) much more useful.

This blog will try and cater for the latter.

Things we might cover: Firefox plugins, website widgets, setting preferences in applications to get the most out of them, highlighting websites and tools, HTML code to embed searches etc on your own website and RSS/XML feeds. We’re also try and provide some background to the systems we use, for those interested. As you can see, some are for anyone who’s comfortable tweaking settings, using RSS feeds etc, and some are a bit more technical, for those comfortable with working with code.

Please do leave a comment, this is new and we want to know if anyone actually finds this useful!

If  this doesn’t sound like your cup of tea, then your best bet is our Library website. It provides links to our Catalogue and Electronic Library, and Infosuss for providing information on how to use them.

All the best,
Chris Keene – University of Sussex Library.