Authorisation Models for National Scale Services Alan Robiette Joint Information Systems Committee

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 (

4 June 2002 TERENA Conference, Limerick 6 Athens: Original Technology Centralised store of userID/password pairs with associated authorisation vectors Devolved administration for each institutions 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 3 rd 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