supporting further and higher education aa(a) – what does it mean to the service provider? alan...
TRANSCRIPT
Supporting further and higher education
AA(A) – What does it mean to the service provider?
Alan Robiette, JISC Development Group
24 Oct 2002 TERENA General Assembly, Prague 2
Overview
• JISC and its activities• AAA in the UK academic and
research community• The Athens service
• Experience with service providers• Both within the academic community,
and with commercial publishers
• Pointers to the future
24 Oct 2002 TERENA General Assembly, Prague 3
JISC activities
• Provision of the JANET network • Via operations contract with UKERNA
• Provision of electronic content• Procurement: national contracts• Some hosting at national data centres
• Environments for teaching and learning
• Development, support and advice• Across all topics listed
24 Oct 2002 TERENA General Assembly, Prague 4
AAA: UK requirements
• A service available to all higher and further education institutions
• ca 180 HE plus 500 FE in total• ca 6 million potential users in total
• Controlling access to a wide range of electronic resources
• Both internally and externally hosted
• Providing usage statistics to both institutions and suppliers
24 Oct 2002 TERENA General Assembly, Prague 5
What is Athens?
• An access management system written specifically to meet these requirements
• Originally designed by a team at the University of Bath (JISC-funded)
• Now owned, developed and operated by EduServ (http://www.eduserv.org.uk)
• Besides JISC, Athens is also used similarly by the National Health Service (National Electronic Library for Health)
24 Oct 2002 TERENA General Assembly, Prague 6
Some recent statistics
• These cover both education and NHS, unless otherwise stated
• 497 FE + HE sites; 769 sites total including NHS
• Approximately 2 million user accounts• Average authenticated access request
per day 85,650 (August 2002)• 51 content providers, offering between
them 249 Athens-controlled resources
24 Oct 2002 TERENA General Assembly, Prague 7
How does it work?
• Athens is a “trusted third party” network service
• Essentially a large database of user ID and authorisation data
• Replicated to provide a resilient service• Each participating college or university
administers its own part of the database• Content providers refer access requests
to Athens for validation, and run special plug-in software to achieve this
24 Oct 2002 TERENA General Assembly, Prague 8
Athens data flows
© EduServ, 2002
24 Oct 2002 TERENA General Assembly, Prague 9
Service providers
• Need to run special software to carry out the dialogue with Athens
• Easier for some than others!• Athens “agent” plugins provided either
as toolkit (C, Java, Perl implementations all available) for integration into supplier’s system
• Or as prepackaged modules (for Apache or IIS)
• Standards of software quality assurance, documentation, etc, are very important
24 Oct 2002 TERENA General Assembly, Prague 10
Athens developments
• “Single sign-on” introduced in early 2002
• Limited-life ticket cached in user’s browser, allows access to all service providers running latest agent version
• Devolution of authentication back to user’s campus
• Initially via campus LDAP directory• Also prototype using client-side X.509
certificate
24 Oct 2002 TERENA General Assembly, Prague 11
Devolved authentication
© EduServ, 2002
24 Oct 2002 TERENA General Assembly, Prague 12
Developments elsewhere
• Athens is a pioneering system: it has served the JISC community well but is now dated in various ways
• e.g. It is proprietary and does not conform to emerging open standards
• Other communities similar to ours are now working on standards-based models
24 Oct 2002 TERENA General Assembly, Prague 13
Shibboleth
• Being developed by Internet2 community (top US universities)
• Much less centralised than Athens• Most messages pass directly between
user organisation and content supplier• Message syntax defined in SAML
(Security Assertion Markup Language)• Strong emphasis on user privacy (user
attributes disclosed selectively)• Not yet fully operational
24 Oct 2002 TERENA General Assembly, Prague 14
PAPI
• Developed by RedIRIS for the Spanish university community
• Strongly campus-centred (all authentication and authorisation takes place at user’s organisation)
• Makes fewest demands on content supplier
• Working at ~25 sites in Spain• Next major version will add Shibboleth
compliance
24 Oct 2002 TERENA General Assembly, Prague 15
What of the future?
• Shibboleth (and SAML) likely to be very influential
• PAPI is moving towards compliance with Shibboleth
• Could Athens also do so?
• TERENA (TF-AACE) and Internet2: a common approach?
• Extremely desirable for dealing with content suppliers
24 Oct 2002 TERENA General Assembly, Prague 16
Athens data flows
© EduServ, 2002
Supporting further and higher education
Questions?