The JISC Core Middleware Call (01/04)

1. Alan Robiette, JISC Development Group <a.robiette@jisc.ac.uk> The JISC Core Middleware Call (01/04)

2. Purpose To develop new and extend existing technologies in access management (AAA), which are Standards-based Aligned with other national and international developments Aimed at future service deployment, in national and/or institutional contexts Designed to address certain scenarios which are currently difficult to handle

3. Present position Two very different services with national scope exist today Athens: username/password based service for unifying access to electronic library-type resources Mainly though not exclusively licensed via JISC consortium deals UK e-Science CA: service for issuing digital certificates for access to Grid-type resources

4. Scope of Athens Over 2 million current usernames Username/password database; maintenance devolved to institutions Around 500 HE and FE institutions use the Athens service Around 200 licensed resources are controlled via Athens A high proportion of the major academic publishers have now implemented Athens

5. So why change? Athens today still uses its own, proprietary protocols Software owned, maintained and developed by EduServ (a not-for-profit UK company) Little international take-up as yet Athens design lacks the flexibility of more recent approaches Not well adapted to inter-institutional scenarios, e.g. virtual organisations

6. The e-Science CA Part of the Grid Support Centre at CLRC/RAL Based on OpenCA software (with local modifications) Verification of user identities carried out by trusted RAs around the community Current scale of operation a few hundred certificates per year

7. So why change? The vision is to extend e-Science technologies to larger communities E.g. social sciences, bioinformatics A general view is that the existing CA will be difficult to scale up In practice larger scale AAA regimes are almost always based around institutions, who are best placed to administer their own members If agreed this would in any case require changes to the e-Science CA hierarchy

8. Key scenarios A next-generation AAA infrastructure must support the following scenarios: Internal (intra-institutional) applications as well as use between organisations Management of access to third-party digital library-type resources (as now) Inter-institutional use – stable, long-term resource sharing between defined groups (e.g. shared e-learning scenarios) Inter-institutional use – ad hoc collaborations, potentially dynamic in nature (virtual organisations or VOs)

9. VO characteristics A VO's members typically belong to more than one real organisation Wishing to share resources across real-world organisational boundaries (often problematic in security terms) VO membership – which may be more or less formal – could be based on numerous criteria (discipline, project, course enrolment, personal interests ...) The authority regulating VO membership could equally take many forms And timescales may be very varied also

10. Link-up with UKERNA location-independent networking project Being pursued by Wireless Advisory Group (but technology also applicable to wired networks) Intention to support “roaming” – authenticated guest connection on other campuses Will require RADIUS infrastructure on participating campuses Eventual international capability Other factors (1)

11. Other factors (2) Internet2 and the NMI-EDIT programme Funded by the US National Science Foundation to develop middleware in much the same areas Initial award 2001 – funding renewed in Autumn 2003 NSF and Internet2 both welcome complementary programme of work by JISC (NMI-EDIT has deferred work on digital rights management and VO authorisation)

12. Principles (1) Authentication is the responsibility of the user's home site Requests to authenticate the user should be routed back to the home site and take place there National infrastructure will require institution-wide authentication services which can be interfaced with other AAA components JISC has commissioned some evaluation work on single sign-on technologies which will be reporting shortly

13. Principles (2) Authorisation is the responsibility of the resource owner Based on attributes supplied by the home site (and/or possibly other authorities) Workable systems depend on agreed attribute naming and sources of authority Progress towards more sophisticated management of digital rights (DRM) requires increased intelligence in the resource's decision engine

14. Shibboleth An architecture developed by the Internet2 middleware community NOT an authentication scheme (relies on home site infrastructure to do this) NOT an authorisation scheme (leaves this to the resource owner) BUT an open, standards-based protocol for securely transferring attributes between home site and resource site Also provided as an open-source reference software implementation

15. How does it work?

16. Standards & technologies Shibboleth message flows defined in SAML SAML = Security Assertion Mark-Up Language, standardised by OASIS Standard attributes mostly from eduPerson and eduOrg schemas But communities can extend these as required Reference implementation uses Apache, Tomcat, Java, OpenSAML

17. Shibboleth pros Good international acceptance US, Australia, some European countries Basic software now well tested Around 30 US universities working with it seriously, plus several content vendors Swiss national HE system deployment Satisfies the main requirements “out of the box” Addresses digital library, shared e-learning and internal use scenarios

18. Shibboleth cons Software still lacks user-friendly management tools In its present state, still quite demanding to install and run Might require outsourced or packaged services for smaller institutions? Relatively unsophisticated authorisation model Single attribute authority No generalised decision engine

19. Architecture recap

20. Coping with VOs Problem: typically a VO involves at least two sources of authority User's identity derives from home institution User's VO membership and privileges derive from the VO's own authority Solution: add more intelligence to the Shibboleth resource manager Policy-driven decision engine Multiple sources of authority

21. Permis What is Permis? A policy-based decision engine Policy expressed in XML (compliance with the OASIS XACML standard planned) Supports multiple sources of authority Decisions based on roles or discrete attributes of users User attributes stored in X.509 standard attribute certificates Stable, portable implementation now included in NMI release

22. Shibboleth + Permis Extend Shibboleth resource manager by incorporating the Permis decision engine Resource owners can then set much more complex policies, embodying their conditions of access Attributes can be gathered from more than one location (and be supplied by more than one authority) Thus meeting the needs of VOs and providing much more fine-grained control

23. Linking to e-Science Many Grid authorisation models ... GGF Authorisation Working Group developing requirements summary + conceptual framework Work in progress on authorisation API (Welch, Chadwick et al.) Incidentally expressed in SAML Though may need to be revisited in the light of recent developments (WSRF etc.)

24. Working with OMII The e-Science Open Middleware Infrastructure Institute (OMII) began operating in January Will develop and distribute robust, well tested software for Grid environments Good channels of communication with relevant parts of JISC Good prospects of developing common technology base (web services, XML, SAML etc.)

25. The role of certificates Identity certificates will still be needed (for a while at least) Initial WS-Security profiles use X.509 certificate as identity token Shibboleth requires institutional signing certificates Also server certificates for SSL/TLS Provide for both types of use via a unified CA hierarchy?

26. Parallel activities Building a national Shibboleth service infrastructure will take place in parallel Existing JISC services are likely to be asked to carry out much of the work On a 2-year timescale, 2004/5 & 2005/6 Will provide a critical mass of Shibboleth- accessible resources This work is separately funded, i.e. Not in competition with the JISC 01/04 call

27. Projects sought A substantial aim is to fund the required development topics Some specific, as noted in the call (e.g. Shibboleth/Permis integration, other Shibboleth extensions, DRM, etc.) More speculative and open-ended work is also acceptable, e.g. setup and management of lightweight VOs; life-cycle management of user credentials and attributes; trust models and delegation

28. Additional work Gaining experience with Shibboleth deployment is a secondary goal Especially where it pushes the boundaries of Shibboleth capability Examples could include multi-institutional e-learning contexts (using the proposed CourseID attribute) Also largely unexplored is the interaction of Shibboleth with institutional portal environments (e.g. uPortal)

29. Who can bid? • Either single institutions or consortia • In the case of consortia a lead site must be nominated and funding will be allocated via the lead site • Partnerships involving bodies outside the sector are allowable • But one of the criteria for assessing proposals will be value for money

30. Further information Technical queries should be directed to Nicole Harris, n.harris@jisc.ac.uk Contractual or procedural queries should be directed to Ann Lloyd, a.lloyd@jisc.ac.uk

31. Questions?