5.3.2 Authentication issues
For a detailed look at authentication issues related to scholarly resources, a good starting point is the JISC and JISC Collections commissioned Service Provider Interface Study. In this toolkit the focus will be on authentication as relates to linking to resources from a learning environment, with an assumption that there will be some level of institutional control over the links provided.
“A wide variety of access methods exist to establish a link between a user wishing to access protected content of a publisher and an existing subscription/license agreement that covers that usage.” (http://sites.google.com/site/publisherinterfacestudy/home/executive-summary)
This ‘wide variety of access methods’ adds another barrier to a user wishing to access an online version of a resource. The variety of mechanisms are described in Section 2 of the Service Provider Interface Study.
Two widely used mechanisms in UK HE are IP authentication and Federated Access Management. IP authentication is often used in conjunction with a URL-rewriting Web Proxy such as EZProxy. The pros and cons of the various approaches are given in the Service Provider Interface Study, and won’t be repeated here.
However, in the case of using a Federated Access Management approach, or a URL-rewriting Web Proxy approach, there is a common issue related to the fact that there is an advantage to adding extra information to the link provided to the reader.
As described in the Service Provider Interface Study, a particular challenge for authenticating a reader of online resources is the ‘discovery problem’. This is described in detail in the study:
“The typical use-case of a user interacting with a service provider and wishing to gain access to restricted content occurs along the following lines:
- The user, using their web browser, connects to a service provider and requests to view restricted content.
- The service provider receives this request. To ascertain whether this person should be granted or denied access, they need to know some information about that person. In the federated world, this means that the user needs to be sent to their home organisation’s identity provider, which will "vouch" for that person and pass across information about them to the resource provider.
- The service provider "discovers" which is the user’s home institution
- The service provider redirects the user to their home institution’s identity provider.
- The user authenticates at their identity provider, which responds to the service provider, letting them know that this user authenticated successfully, and often providing some information about that user.
- The service provider receives this information, and then either grants or denies access based upon the information it received.
In the logic flow presented above, step 3 is the crux of the discovery problem – how does the service provider figure out which is the home institution/identity provider of the user?”
One ‘solution’ (more accurately a way to avoid the problem) is called ‘IdP-initiated SSO’ (Identity Provider inititated Single Sign On). This is where the institution will provide links to online resources in a way that the reader is first directed to the institutions ‘identity provider’ (i.e. authentication page).
An example of this is the following link to Ovid from the University of Cardiff web pages[19], a service provider for databases and other online content:
https://idp.cf.ac.uk/idp/profile/Shibboleth/SSO?providerId=https%3A%2F%2Fshibboleth.ovid.com/entity&target=cookie&shire=https%3A%2F%2Fshibboleth.ovid.com/Shibboleth.sso/SAML/POST
Rather than direct the reader directly to the Ovid website, it rather directs the user to a local authentication page, but includes within the URL information about the remote resource the reader wishes to access. In this way the user can authenticate in a straightforward manner, and then be redirected (without further intervention on their part) to their desired destination.
A similar approach can be taken with URL-rewriting Web proxies. In this case the reader is directed to a web proxy. At this point they will usually be prompted for an institutional login. An example of this is the following URL from the Open University library (from http://library.open.ac.uk/find/databases/index.cfm#O):
http://libezproxy.open.ac.uk/login?url=http://www.oxfordartonline.com/subscriber/
As can be seen, once again information about the desired destination is passed within the URL that the reader follows, but in this case rather than be redirected to this URL, instead the Web Proxy (in this case http://libezproxy.open.ac.uk) will act as an intermediary for all further requests for pages from the resource (http://www.oxfordartonline.com/). It will appear to the service provider that the reader is requesting pages from within a registered IP range and so no further authentication is required.
As the Service Provider Interface Study notes, “this approach can be very effective”, and where links to online resource are being provided from references within an institutionally controlled environment, some consideration should be given to taking advantage of this.
No Comment