Authorisation Models for National Scale Services

Alan RobietteJoint Information Systems Committee

agr@westgate.f9.co.uk

4 June 2002 TERENA Conference, Limerick 2

Outline

• The authorisation problem• History JISC national services in the UK• Athens – present and future• Other emerging architectures• Conclusions

4 June 2002 TERENA Conference, Limerick 3

The Authorisation Problem

• Assume the user is known • i.e. has successfully authenticated in his/her own

security domain

• The user has attributes determining what he/she is allowed to do

• The resource has use conditions set by the resource owner

• To make the access decision requires mapping one to the other

4 June 2002 TERENA Conference, Limerick 4

JISC Content Services

• National-scale contracts are negotiated for all of UK higher and further education

• ~180 HE and ~450 FE institutions• ~5 million people (staff & students combined)

• Individual institutions decide whether or not to subscribe to each deal

• Suppliers currently required to implement two methods of access control: either IP address checking or Athens

4 June 2002 TERENA Conference, Limerick 5

Athens: History

• Developed at University of Bath, to unify ID/password across range of local services

• Extended to cover JISC data centres at 3 locations (Bath, Manchester, Edinburgh)

• Subsequently extended to a range of commercial information suppliers

• Now owned and operated by EduServ (http://www.eduserv.org.uk)

4 June 2002 TERENA Conference, Limerick 6

Athens: Original Technology

• Centralised store of userID/password pairs with associated authorisation vectors

• Devolved administration for each institution’s users

• Software plug-ins for data suppliers’ servers• Authentication dialogue always encrypted• Central database replicated for resilience

4 June 2002 TERENA Conference, Limerick 7

Athens: Scale

• Over 400 HE/FE institutions use Athens• Plus a growing number of sites in the National

Health Service (National Electronic Library for Health)

• Over 1 million user accounts in database• Over 150 information resources controlled

by Athens• Publishers include Beilstein, EBSCO, ISI,

OCLC, Ovid, OUP, Proquest, Silver Platter

4 June 2002 TERENA Conference, Limerick 8

Athens: Perceived Problems

• Athens username space is distinct from campus username space

• Leads to problems with data quality and data maintenance

• “Trusted third party” model not suitable for local authentication

• Protocols and software proprietary to EduServ

4 June 2002 TERENA Conference, Limerick 9

Athens: New Developments 2002

• Single sign-on implemented Spring 2002• Session-key/token stored as cookie• All access requests traverse auth.athensams.net

• Athens Distributed Authentication: first pilot planned for Summer 2002

• Interface to on-campus authentication service• Maps local ID to Athens “permission set”

• Also proposal for authentication via X.509 certificate

4 June 2002 TERENA Conference, Limerick 10

Athens Distributed Authentication

• DSP = Data Service Provider (may be local or remote)

• XAP = Extensible Authentication Point (Athens specified, may be locally tailored)

• UAS = User Authority Service (maps ID to permission set)

4 June 2002 TERENA Conference, Limerick 11

Component Summary

• At local site:– Authentication service– Mapping to permission set (Athens format)

• At central (Athens) domain:– Session state maintenance– History, logging and statistics

• At data supplier:– Software responder for Athens management

server (essentially still trusted 3rd party model)

4 June 2002 TERENA Conference, Limerick 12

Other Schemes

• PAPI (RedIRIS)• Distributed architecture: authentication and

authorisation both carried out at campus (i.e. campuses have to be trusted by resource owners)

• But in latest version, Group Point of Access (GPoA) federates management of access to multiple PoAs – starts to look more like an Athens model

• PAPI is open source and in use in a number of sites/consortia in Spain: how can it be scaled up to a national model?

4 June 2002 TERENA Conference, Limerick 13

PAPI Architecture

Basic PAPI architecture with PoA only

4 June 2002 TERENA Conference, Limerick 14

Other schemes (cont)

• Shibboleth (Internet2)• Devolves authentication and attribute assertion to

campuses• Resource owner requests attributes from campus

and makes decisions based on the response• Model allows both campus and user control over

attribute release (strong emphasis on privacy)• At first sight contains no central elements: but

“Shibboleth Clubs” are needed to agree policy etc.

4 June 2002 TERENA Conference, Limerick 15

Conclusions (1)

• Athens began with a strongly centralised model – but is now devolving more and more functions and starting to resemble a PAPI-like model

• PAPI and Shibboleth began as designs for models based on bilateral agreements between host institutions and resource providers – but are thinking more and more about policy for larger consortia

4 June 2002 TERENA Conference, Limerick 16

Conclusions (2)

• As services expand to a national scale, policy issues become very important

• If not absolutely essential, some central management framework is extremely useful e.g. in dealing with commercial publishers

• Although superficially very different, close comparison of AthensNG, Shibboleth and PAPI reveals many components in common