One Password For Everything

Andrew Cox reveals how the CANDLE project is developing a system to greatly improve users' access to licensed networked resources, such as electronic journals.

Introduction

The Cactus system being developed by the partners in the CANDLE project is a prototype of the management tools information services need in the age of networked electronic resources [1] [2].

Our current focus of development is in the area of authentication and authorisation. Cactus will simplify logging on for users by, in effect, remembering passwords for them. Users will be able to connect to secure resources from anywhere, not just on campus. On campus they will get the added benefit of seeing a customised set of information resources and applications that prioritizes what is relevant to them. The collection of data on who is using what will be improved, providing the knowledge upon which to rationalise subscriptions. The control features within Cactus will give managers the tools to scaleably manage user groups so that it is possible to move away from simple institution-wide licences to low cost licences for small groups for short periods.

The Problem

South Bank University has just passed an important landmark. We now subscribe to more electronic journals than print ones. We are not alone. At least one library has now cancelled all its print journals, and only subscribes to electronic journals [3].

But the management of electronic journals, indeed any networked information resources raise many problems. The partners in the CANDLE project recognised the possibility of providing solutions to some of these problems by building on an existing system developed in the CaseLibrary project.

One of the key issues with networked resources is authentication and authorisation. Authentication is the process by which you establish an identity online. Authorisation is the process by which it is decided which resources this identity is eligible to use.

Passwords are a familiar approach. The problem is they are not very secure. People share passwords despite the strictures not to. And we all suffer from password overload. We have difficulty remembering all our different passwords. We either waste time going to the helpdesk to have forgotten passwords reset or we write them down, pretty much blowing any security they might have.

IP address checking is another approach. This works on the logic of determining your access rights on the basis of where your machine is. If your machine is on campus you must be a member of the University and so entitled to use a service the institution has subscribed to. It's a very attractive approach because it is transparent to the user, and relatively easy to administer. But increasingly people want to work from off campus.

In the UK we have the Athens system which offers a great simplification of password schemes, and with more and more services offering Athens authentication life has been made a lot easier for us [4]. But there are still lots of services that do not offer Athens authentication. Significant among these are the diverse range of locally generated web materials needing secured access. These resources must be recognised as being as much part of the same problem of proliferating passwords as licensed materials. And administering Athens if everyone is to have a password is still a headache.

Benefits Of Improved Authentication Schemes

How to accomplish authentication and authorisation in a way that is easy for users, efficient for administrators and secure has been the cause of considerable debate [5] and [6]. The benefits are clear.

• It will be simply easier for users to access resources if authentication processes can be simplified, and as far as possible work behind the scenes. The ideal is single sign on - where I log on once, then somehow behind the scenes my authentication credentials are passed on to other resources I want to use.
• Users will be able to log on from anywhere and get into the resources, including off campus.
• The administrative overhead of handing out passwords or resetting them will be reduced.
• Services can be personalised for individuals or groups. Thus when a user logs on they can be shown electronic resources relevant to them, making it easier to find their way through the jungle of resources libraries are trying to promote to users.
• Cross searching of multiple licensed and other secured databases will be possible.
• If we can reliably restrict use of a service to one group, say, it might be possible to negotiate more cost saving licences; rather than having to sign licences that cover every member of the institution.
• We would be able to collect better management information about use. IP addressing cannot distinguish between user groups only between computers, which means we cannot easily tell the pattern of use between staff, undergraduates or postgraduates, for example.

Cactus should deliver many of these benefits.

Background To The Project

CaseLibrary

CANDLE is a further enhancement of software a number of the partners developed in the CaseLibrary project [7]. CaseLibrary was essentially developing a system for managing resources on shared workstations. Within the system you can define and associate terminals, users, user groups and resources (including local information sources, applications like Word and printers and filestore). Thus you can say this group of users can use this application on these terminals. This user has this printer. The aim was to provide an efficient way to manage resources and measure actual usage.

Features of the system are:

• Centralised network user and resources configuration and administration.
• Customised desktops and personalised configuration of applications.
• Detailed resource usage monitoring and accounting.
• Usage quotas enforcement by session, day, month, and year. The idea was that usage could be rationed by giving users a quota and setting different tariffs on the use of different applications depending on location, time of day and so forth. The object was to even out usage of computers.
• Messaging and remote shutdown facilities. Messages could be broadcast to individuals or groups of users. At the end of day users could be shut down gracefully after a warning message.
• Within CaseLibrary we also developed an easy to user Z39.50 client called ZNavigator that could be customised at start up by the Cactus system.

CANDLE

The main thrust of development in CANDLE (1998-2000) is to expand the system to manage networked information resources.

The software has been migrated to NT and SQLServer and the CaseLibrary functions are now available for NT and Windows 95 or 98 clients.

The partners in the CANDLE project are:

• Enware S.A. a software development company based in Madrid
• Coordinamento Biblioteca, Università degli Studi di Firenze, (University of Florence)
• The HYpermedia and DIgital Libraries Research Group (HYDILIB), Department of Informatics, National and Kapodistrian University of Athens
• LITC, part of Learning and Information Services, South Bank University, London
• Blackwell's Information Services, Oxford

The Cactus Approach To Authentication/Authorisation

Basically our approach to authentication/authorisation is to use an 'intelligent' proxy, which when a user wants to use a service checks whether the user is registered for that resource, and if they are steps in and handles authentication. Once logged on at the beginning of a session the user does not have to remember any other passwords.

The key steps followed to complete a user's request are:

1. The users requests an object (web page, pdf, etc) by clicking a URL link initiating an http request.
2. The URL is checked against a list of URLs that are blocked, i.e. in a list of proscribed sites (an optional feature). If the URL is blocked, the request fails and the user is notified.
3. The request is forwarded to the Candle Cactus server, which checks the users' details to decide whether he/she is allowed to access this resource.
4. If they are the URL is checked against the cache to see if this page has been saved locally. If so, the page is delivered to the user.
5. If not the Candle Cactus server replies to the publisher's site with credentials for authentication, e.g. the individual's username and password.
6. The requested object is returned from the publisher and then delivered to the user.
7. The action is logged.

To reduce load on the proxy we are using Proxy Autoconfiguration (.pac) files which only send http requests through Cactus if they are to a server with licensed material on it. The user's browser picks up the .pac file at the beginning of their session from a central URL, so changes for all users can be made by administrators.

Only on campus machines that have the cactus client installed will get the full benefit of a customised desk top. For off campus users there will simply be a web page where they will be challenged to authenticate themselves. This authentication exchange will get users onto the proxy, from which point the benefits of simplified authentication will be enabled.

The Benefits of Cactus

The benefits of Cactus are:

• Connecting to networked resources will be easier. There will be less time spent resetting passwords.
• Users will be able to log on to licensed materials from off campus, with the minimum of changes to their software.
• On campus users will have a desktop that reflects their needs, making it simpler for them to correctly identify the best sources of information.
• We shall be collecting consolidated information about usage. An important aspect of the project will be to look at how we can effectively mine management information from logs generated by the system.
• Although not highly secure, the system will be an improvement on password systems. It will not be necessary for users to think up and remember secure passwords. They will not know their passwords to be able to trade or lend them.
• The administration software has been designed to be relatively simple to use. Multiple administrators can add and configure resources. This will enable those such as faculty librarians, who know about the resources to manage access to them. It will reduce the burden on network administrators.
• It will be possible to manage users and user groups at quite a fine granular level. Thus it could be possible to negotiate cheaper licences with publishers, on the basis of guaranteeing that only small numbers of users are using a resource.

Issues

We are aware some potential stumbling blocks with our approach.

1. Effects on network performance. A complicated proxy will add to the potential bottleneck of existing firewalls, caches and proxies that stand the between user and the resources they want to get at. It is essential for users not to go through the Cactus proxy for everything or there will certainly be an overload. Having acknowledged this as a potential problem we are designing the proxy so that it will not slow users down. Real world testing within the project will discover the appropriate specifications.
2. Initial Sign on must be secure. For off campus users there is a need to establish a secure means of authentication at the beginning of the session with the proxy.
3. Relies on user correctly changing settings to proxies. There is widespread scepticism about users' ability to do understand how to change browser settings, even though it is quite a simple reconfiguration. In some cases ISPs may not allow changes to the proxy settings. And probably distance learners at their workplace will not be able to.
4. The Auto configuration approach is browser specific. This means it is slightly more complicated to implement, requiring a script to detect which browser the user is using before determining how to express the auto configuration. This is a purely technical problem that we believe we can solve.
5. Problems with shared workstations. There are risks of unauthorised use of services, if the user does not log out of a machine after using it. Again there are technical solutions.
6. Management Information may be difficult to produce. It will be complicated to tie up the proxy logs and publishers site information to work out who accessed what.

There are other possible technical solutions to authentication problems such as digital certificates. But we believe the Cactus approach using a proxy is the best available at the moment:

• it works now - whereas other solutions such as certificates are immature technologies;
• proxies work across protocols (though we are only dealing with Web based resources within the scope of the CANDLE project);
• since the publisher sees only the proxy accessing his site, the privacy of individual user is protected at this point;
• it is a relatively simple and cheap approach;
• it requires relatively minor changes to the users' software.

Project Status and Exploitation

An alpha version of the Cactus software is being installed and tested at the Consortium sites. We hope soon to have a beta version soon that can be trialed on a small scale, then rolled out through the consortium institutions and to three official test sites.

Any other institutions including from outside Higher Education will be welcome to trial the software. We are already talking to some half dozen institutions. If your are interested contact us.

We know that there is a demand for the functionality Cactus offers. It is obvious for example that public libraries, Internet cafes and museums offering access to information resources need something like our system. And we have many ideas about how the software could be further developed.

The UK Joint Information Systems Committee have given us funding to further develop the system to allow us to authenticate users with Athens. If we can store Athens passwords in Cactus we will not have the headache of distributing them to users or sorting out questions about lost passwords. Within the project we will be exploring how we can bring in a wider range of access restricted institutional information sources into the system.

Conclusion

Complimentary to systems developed by projects such as Pride, Decomate and Agora we see the Cactus system as a substantial building block for an integrated management system for the digital library.

References

1. CANDLE homepage, LITC, South Bank University
   URL: <http://www.sbu.ac.uk/litc/candle/>
2. CANDLE Project Fact Sheet, European Commission
   URL: <http://www2.echo.lu/libraries/en/projects/candle.html>
3. CANDLE-Athens project, CANDLE
   URL: <http://litc.sbu.ac.uk/candleathens/canath.html>
4. "Taking some big steps towards the digital library - lessons learned from the reengineering process at the Technical Knowledge Center & Library of Denmark", Lars Bjornshauge, Vine 110, pp. 16-22
5. Athens homepage,
   URL: <http://www.athens.ac.uk/>
6. A White paper on authentication and access management issues in cross-organizational use of networked information services, Clifford Lynch, April 14th 1998
   URL: <http://www.cni.org/projects/authentication/authentication-wp.html>
7. Authentication and Authorization: a Guide, CANDLE
   URL: <http://www.sbu.ac.uk/litc/candleathens/>
8. CaseLibrary homepage, LITC, South Bank University
   URL:<http://litc.sbu.ac.uk/caselib/>

Author Details

Andrew Cox
Senior Researcher
LITC
103 Borough Road
London
SE1 0AA
UK

LITC URL: <http://www.sbu.ac.uk/litc/>
Tel: +44 020 781 7058
Email: <coxam@sbu.ac.uk>

Andrew Cox is senior researcher at LITC, a research unit in Learning and Information Services, South Bank University. LITC are involved in a number projects funded by the EC (Candle, Easel, Pride) and JISC (Heron, NewsAgent, Candle-Athens). We publish specialist publications for the LIS community including Library Technology and Vine. We also do consultancy work, recent customers have included the British Library and the National Health Service.

For citation purposes:
Andrew Cox, "One Password For Everything", Exploit Interactive, issue 5, April 2000
URL: <http://www.exploit-lib.org/issue5/candle/>

[HTML Validation] - [Accessibility check]