Stories

D-Lib Magazine
March 1998

ISSN 1082-9873

Implementing a National Access Management System for Electronic Services

Technology Alone Is Not Enough

Norman Wiseman
JISC Head of Programmes
University of Nottingham
Nottingham NG7 2RD
United Kingdom

[email protected]

Introduction

Clifford Lynch, announcing the Coalition for Networked Information (CNI) initiative in authentication, called for participation in the development of 'an infrastructure for facilitating electronic commerce in content among organisations'.

The ATHENS access management system was introduced in 1996 and then extended in 1997 to provide access control facilities for all the national data centres and services in the United Kingdom. The service, though relatively sophisticated, is not as technologically advanced as that proposed in the CNI infrastructure. It operates on a smaller scale than envisaged by Clifford. It has, so far, only involved a small number of agencies outside the education sector; and it has been promoted by a central coordinating body with some influence in the sector. Even so, it has been and remains a major challenge to persuade the stakeholders in the institutions to accept the additional work that has come about through its introduction.

The problems of implementing a security infrastructure have always been seen as a technological challenge. The lessons from ATHENS could suggest that success will only be achieved if at least equal attention is paid to the needs of those who will have to manage the final system as to the technical detail.

Background

Not everyone is familiar with the electronic service infrastructure in the UK, so a few words of explanation will be helpful at this point.

Much of the UK higher education information technology infrastructure has been set up by the Joint Information Systems Committee (or JISC). The JISC is funded by all the UK higher education funding bodies in recognition of the benefits that a centrally managed infrastructure can bring in the area of information services. The JISC funds the national network, JANET, and runs a range of data centres and services on behalf of the higher education and research community. There are three data centres at Bath (BIDS), Manchester (MIDAS), and Edinburgh (EDINA), and network, data and advisory services spread across the country. The JISC also funds research and development programmes to trial new services and evaluate technologies.

At the end of 1996, it became clear that the proliferation of services and the transformation of projects funded under the eLib programme into full services were creating an urgent need for a unified, national access management service. The three data centres had, for very good reasons, taken different approaches to controlling access in the past but were willing to work towards a unified access arrangement, provided that a unified naming convention could be agreed. Other existing services and emerging new services appeared willing to adopt a ready-made access management system if it met their requirements.

The alternative, where each service developed or maintained its own systems, would result in chaos. Users would be faced with having to remember dozens of different user id's and passwords. Information services staff in institutions would have to maintain dozens of different administrative systems. The longer this situation continued, the more entrenched each service's system would become and the less inclined they would be to migrate to any future unified system. Even more worrying, a proliferation of authentication systems could discourage end-users, setting back acceptance of electronic services for research and learning.

The Development Project

The JISC commissioned a number of reports which set out the technical options available. An ideal solution, along the lines proposed in the recent CNI call, appeared some years off - and still does today. The decision was taken to explore the opportunities that extending the existing ATHENS system could offer as an interim solution, while anticipating the emergence of a wider infrastructure for electronic commerce in the medium term.

A meeting of the data centres, NISS (the developers of ATHENS) and representatives of the user community who were already using the product was held in April 1997. It was agreed that ATHENS had the potential to offer a unified approach within a very short time and at a very modest cost, provided that a number of specific requirements of the data centres could be met. Approval was given to begin development to provide an operational system by the start of the next academic year.

The JISC had to be confident it could provide a working solution in the time available and at little cost. Kerberos-like and other certificate-passing systems for inter-institution working were ground-breaking developments and were therefore considered too technically arduous to deploy, risky, expensive and unlikely to deliver a service within months rather than years.

It was agreed that an acceptable system would have to offer the following functionality:

Many of the technical challenges required to extend ATHENS to provide this functionality were already understood by the development team. The work needed to understand all the user and administrator issues which would arise from its implementation was a far greater challenge. Before describing how this was undertaken, it will be helpful to explain how ATHENS works.

ATHENS: Overview

Technically, the system is straightforward in its operation.

Firstly, a data service provider will apply access controls to the data they hold. Sometimes the whole of a data set is protected but typically access to part is unrestricted to permit browsing of contents or indexes. "Services" may, for example, comprise subsets or the whole of individual data sets, or an entire digitised journal, a volume or an individual copy.

The service providers notify the central ATHENS administrator when new services become available. The central administrator registers the service with ATHENS and will grant an institution access when notified by the licensing agent that the license fee has been paid or other pre-conditions for using the service have been met.

Local administrators at the various institutions control who at their respective institutions is authorised to use services, according to the conditions of use. All current access control information is held on the central server and accessed via a web server using Secure Socket Layer (SSL) security. Local administrators can only examine information about their own institutions. Audit features on the central database give the data owners confidence that licensing conditions are being applied correctly.

The local administrator manages a rights table which has an in-depth user profile for every account in the system. This includes:

Data Service Providers can apply three different authentication mechanisms: IP address checking only, authentication by username and password, or both. IP address checking will always be implemented for group user names, but individually registered users can have access to services without IP checking, provided the licence conditions permit this. They can therefore access services when away from their home institution or via Internet Service Providers.

Scalability is an important issue in providing a viable service. Currently, ATHENS has been scaled to deal with more than 1.7 million users, each with access to more than 30,000 services. While it has not been possible to test this in practice, early indications show that this figure will be achievable and can probably be extended.

ATHENS: Operation


Figure 1. ATHENS Architecture

A user will access a data service using a web browser, Telnet, or other interface. When the user first requests access to a protected service, the server will call ATHENS to authenticate the identity of the user by means of a user name and password combination and establish whether the user is authorised to access the service. If not, then the user is directed to contact the local information officer to obtain further information. If the user is authorised, access is granted. After the first authentication is completed, authorisation checks on other service requests are carried out without further user intervention.

Satisfying the User Requirements

The principal beneficiaries of the new arrangements would be the end-users. They would have a simplified interface and a single user name and password to remember.

However, it had been apparent from an early stage that a move to a coordinated managed service would immediately create substantial extra work for administrators at institutions. They would see long term benefits, through having to manage only one access control system rather than many different systems, but in the short term, ATHENS would require work at every institution to register or re-register users.

The workload would be especially high for those institutions which wanted fine granularity of control over access to resources or wished to provide access to students and staff off-campus without the limitations of IP address checking; in this case every user would have to be individually registered. The scale of this problem can be recognised if the total potential user population is considered: there are 1.7 million students and staff in UK higher education, one third of whom (approximately) change every year.

Therefore, if ATHENS was to have any chance of success and acceptance, it was recognised that a strategy was needed to minimise impact on information services staff. The strategy had four main elements:

The ideal solution would have been to have all access management held and controlled locally. However, technology that will allow this on the scale envisaged is not currently available. The ATHENS system, therefore, holds access data centrally, albeit with replication across multiple servers to provide resilience and to minimise network bottlenecks. The administrators' interface permits local control of the information on the remote server, and its design is critical if the system is to be accepted easily and used effectively.

Once the initial design was complete, an extensive series of workshops was held around the country to demonstrate the interface. At the same time, the opportunity was taken to discuss the issues which institutions would face when implementing the service: delegation of local control, the relative merits of group and individual user names, and linking ATHENS registration with student registration systems.

Feedback from the participants on the interface design was successfully used to tailor the final product so that it has had good acceptance in the user community. However, attempts to stimulate discussion within institutions about the wider issues, many of which are linked to institutional information strategies, were less successful. Some sites have taken this on board and are actively working on the problems, or recognise that the coming summer vacation will offer an opportunity to address the issues. Others have still to recognise all the implications, and more work will be needed over the coming months to increase awareness of these important issues.

The overall length of the name in earlier versions of ATHENS had been set to twenty characters. The data centres agreed to a new limit of only eight characters because the unified names had to provide access to some legacy systems which would only accept names up to this length.

It was felt essential to grant institutions control over ATHENS user names, but the first three characters were retained, to identify an institution and prevent duplicate usernames. In practice, the retention of three characters at the head of a name has not proved a problem, but there is growing concern over the limit on length. Many sites have naming schemes which use between six and ten characters. Quite reasonably they would prefer to see the ATHENS user name to be the same as a user's local identifier, prefixed with the site code. Currently, the implementation of longer names is under discussion, and it is hoped that this request from the community can be satisfied, while still meeting the needs of the data service providers.

Some degree of anonymity is provided through ATHENS. Though this is not seen as a major issue in the UK, discussions at CNI reveal it to be more so in the USA. ATHENS will permit a service provider to know a user's home institution but not their identity, provided the local naming scheme is anonymised. However, ATHENS does store personal details, accessible only to the local administrators, which enable them to deal with any abuse or misuse of services.

With a plethora of different staff and student registration schemes in use in UK higher education, designing a simple, transparent interface to load data directly into ATHENS would be mammoth task. The problem has been addressed in several ways. Firstly, there is an interface which accepts information from many of the commonly-used spreadsheet and database packages or in comma delineated forms. Secondly, there is an automated name creation facility. Thirdly, a bulk loading service is available to institutions to relieve them of at least part of the effort required to install and check information.

A further tactic to reduce pressure on local administrators was to implement a hierarchical local administration system. This permits a site administrator to delegate administration within an institution, thus spreading the work load. For example, there may be faculty and departmental administrator levels, each inheriting rights from the level above or from the site administrator. There is an overall limit on the number of levels to avoid over-complex and unworkable solutions.


Figure 2. Hierarchical Account Management

There is a rich set of features which govern the granularity of control. At the finest level, every member of an institution can be issued with an individual user name. If this level of control is not required, "Group identifiers" can be used: these can be assigned to classes, to courses, to a whole year's students or, at the coarsest level, to the whole institution.

Administrators have the option of creating all the personal user names themselves or enabling self registration. The former provides the most control, and removes the possibility of abuse, but the latter minimises the effort required and therefore has proved popular in some instances. Experience has shown, however, that sites are only using this feature as a short-term expedient and wish to move away from self-registration as soon as resources permit.

Finally the administrators have control over expiry and deletion of user names. Personal and group identifiers can be set with limited lifetimes. Hence all student id's could be set to expire at the end of a term or an academic year; groups associated with courses could expire at the end of the course, or after a set number of weeks. Deletion or renewal can then follow as required.

Support for the Administrator

With such a range of functions and options, and faced with what could be a considerable work load, it is vital that administrators have good support from the very start. It was a key deliverable of the development project that, in addition to the training workshops mentioned earlier, there should be

The series of workshops for administrators is continuing, with each changing in response to earlier events, and feeding into the continuing development programme. The next version of ATHENS will include a number of important additional features, including many which have been requested by the community. In particular, the administrators will have a set of analytical and reporting tools which will help them determine patterns and levels of use.

Data Service Providers

A similar level of attention was paid to the other important partner - the teams who run the data services at the data centres. They have a very close relationship with the administrators, and end users too, and add a lot of value through their understanding of the data and how it can be used. It was vital to involve them at all stages and to understand their requirements. There were regular meetings of all parties to ensure that their needs were not overlooked, and a steering group will be set up soon to ensure that their needs, and the needs of the users, are formally recognised in future developments.

It was originally intended to implement the ATHENS interface on a limited number of common web servers and via Telnet to meet the tight deadlines. Pressure from the service providers for a programmers interface delayed the launch by a few weeks but created a valuable resource. It has permitted service providers to retain individuality in the delivery of their services, to extend the range of value-added features they can offer, and it increases the range of services which can be controlled by ATHENS.

Acceptance

ATHENS is already a stable, heavily used service after only a few months of operation. It would be "economic with the truth" to suggest that its introduction, and the work that goes with it, has been universally welcomed. However, the enormous effort that has gone into communication with the user community - and in showing a willingness to respond to their needs - has paid off.

The effect this strategy has had on generating acceptance should not be underestimated. Most of the modifications to the service that have been requested have been cosmetic or in the detail, but these are exactly the modifications which create good will and acceptance in the community. There has been little need to revisit any of the major technical features, other than the length of user name issue reported earlier.

At present almost every higher education institution in the UK is using the product in a variety of different ways. More than 240 sites are registered; 40 major database and commercial software mirrors are accessed through ATHENS; and there are more than 350 domain and departmental administrators registered in the system.

Many institutions are awaiting the summer vacation to revamp their access control scheme, prior to the next academic year, but there are already more than 50,000 individual user identifiers in the system. This is more than was expected at this point, only three months after the initial launch, and an indicator of the popularity of the system and the functionality it offers.

Where Next?

The service will shortly be extended beyond the original four data service providers (BIDS, EDINA, MIDAS, and NISS). A number of education and commercial service providers and development projects are preparing to join ATHENS in the near future.

The next release of ATHENS is imminent, and some if its features have already been described above. A range of other features is planned or is possible, depending on demand from the users and data suppliers and on developments in technology.

For example, it is a natural extension to use the service to control access to local web and telnet services. A site can then use a single access management system to control access to both its Intranet and to national services. Control of regional services, possibly for sites on a Metropolitan Area Networks, is another opportunity that is expected to be developed.

Discussions are taking place with data suppliers outside the community to offer higher education access to their products via ATHENS. The attraction for them is that the authentication and authorisation details of their users is managed for them, and they do not have to set up systems of their own. For the community, access can be managed within the existing scheme.

Another feature which will be available soon is the user profile facility. Users will be able to store information about their information needs and histories of previous searches in ATHENS, provided that the data service providers enable this option. With the growth in scope and complexity of information services, the ability to apply some intelligence to the information searching and gathering process will become a valuable tool.

ATHENS has been designed to be flexible in the face of changing technology and user demands. Interfaces to smart-cards, to certificate servers and features such as control of concurrent usage could all be implemented, given the need. Some of these features will almost certainly be introduced in the near future.

Unexpected Benefits

ATHENS has produced many unexpected benefits or has highlighted significant issues. For example:

A fuller analysis of the benefits can follow after further experience has been acquired and is likely to be reported on later in 1998.

Further Information

Information about ATHENS is regularly made available on both the ATHENS and JISC web pages. Papers and reports on related authentication issues and activities will also be made available on the JISC pages.

And finally...

I would like to thank everyone in the development team at NISS for their tremendous efforts in this project. Their hard work, willingness to listen to the customers and then to implement requests have made it possible to implement ATHENS quickly and to get it off to such a successful start.

Copyright (c) 1998 Norman Wiseman

Top | Magazine
Search | Author Index | Title Index | Monthly Issues
Previous Story | Next Story
Comments | E-mail the Editor

hdl:cnri.dlib/march98-wiseman