Accessing electronic journals
| Pages | 81-85 |
| DOI | https://doi.org/10.1108/03055720010804203 |
| Date | 01 September 2001 |
| Published date | 01 September 2001 |
| Author | Martin Radford |
| Subject Matter | Information & knowledge management |
VINE 124 — 81
Accessing electronic
journals
by Martin Radford, Information
Services, University of Bristol
Many electronic journals are licensed on the
basis that allowing con nections from a
specified IP addres s range is “good eno ugh”
as a mechanism for identifying authorised
users. This is inadequ ate when legitimate
users wish to conne ct from home via a
commercial ISP. Th is paper discusses a novel
approach to allowin g this in a secure fashion,
using Squid on Unix .
Introduction
One question that must immediately arise when a
publisher decides to make journals available on the
web by subscription - how to identify those author-
ised to access them? One approach is to give
usernames and passwords to the institution to be
issued to users; others use centralised systems such
as Athens1; others satisfy themselves by allowing
connections from the range of IP addresses allo-
cated to that institution, and trusting the institution
itself to ensure that only authorised users have
access to computers with those addresses.
The last choice is the one that is most convenient
to university libraries - the user has seamless
access to the journal, and there are no passwords to
maintain or issue. While this is satisfactory for
users on an institution’s own network, it makes
access impossible for anyone who wants to access
the journal from their dial-up or broadband con-
nection at home (unless the publisher has a
secondary authentication mechanism available).
One possible solution to this problem is to
configure a proxy server to act as a go-between.
Instead of the browser (or “client”) connecting
directly to the “ origin server” (i.e. t he web s erver
that holds the content), the browser asks the proxy
server for the content, and the proxy server fetches
it on the client’s behalf. Most proxy servers will
also keep a copy of the data (“ cache” it) in case
another client requests the same content later. This
neatly solves the problem of remote access — the
proxy server is located on an institution’s network,
and the request appears to the origin server to have
come from the pr oxy.
The University of Bristol, in common with many
other universities in the UK, runs a caching proxy
service in an attempt to limit its use of chargeable
trans-Atlantic bandwidth. We use the open-source
Squid software to do this.2 With the necessary
infrastructure already in place, we decided that we
could use our proxy servers to open access to
journals to our off-site users. However, we could
not just open the service without ensuring that (1)
we had some way to identify legitimate users, and
(2) we would n ot be creating any netw ork secu rity
problems. The main focus of this paper is to
explain the issues we considered and what meas-
ures we came up with to satisfy them.
How proxy authentication
works - briefly
The main difference between authenticated and
non-authenticated proxy use is that the web
browser sends the user’s credentials at the same
time as it requests each URL. This prompts three
questions: first, how does the browser know that it
needs to use these credentials; second, how does it
get them from the user; and third, in what form are
they sent to the proxy server.
1. A browser first requests the URL from the
proxy as normal. If the proxy decides that it
needs authentication, it sends back a “Proxy
Authentication Required” message (HTTP
code 407), which includes a string
identifying the “realm” of the proxy.
2. The browser prompts the user for a
username and password for the realm
specified in the 407 message.
3. The credentials are formed by taking the
username, adding a colo n character, t hen
adding the password to the end (i.e. in the
format username:password). This is then
encoded using Base64 encoding (which
converts a string of arbitrary ASCII
characters into a string consisting of only the
characters A-Z, a-z, 0-9, + , /, and =), and
sent together with a new request for the
URL.
To continue reading
Request your trial