Core Middleware Development

1. Core Middleware Development Nicole Harris, Programme Manager, JISC Middleware Team

2. To be Addressed • What is Middleware? • Why change now? • What are we doing? • Core Middleware: Technology Development. • Core Middleware: Infrastructure. • Partnerships. • What’s Coming up? • Middleware Timescale. • Key Message for now.

3. What is Middleware? • The JISC uses the term middleware to describe the process of helping institutions to connect people to resources.  • Technically, it can be viewed as a layer of software or 'glue' between the network and applications.  Middleware can be shared by many applications serving various purposes in different environments.  • People are not isolated.  They are affiliated to many different groups, institutions and collaborations, and work within the existing structures put in place by these affiliations.  This will include existing institutional middleware that supports the day-to-day management of internal collaboration.  JISC development work supports existing practises whilst enabling people to work beyond institutional boundaries, drawing on a much wider range of relevant and essential resources. 

4. Middleware is Everywhere • Information Environment. • eLearning Technical Framework. • GRID Middleware / VRE. • Common Information Environment: • JISC, Becta, Culture Online, DfES, eGovernment Unit, eScience Core Programme, MLA, The National Archives, NeLH, UKOLN.

5. What is Core Middleware? • Core Middleware can be defined as the central services that are essential to middleware as a whole. • These are: • authentication, • authorisation, • directory services, • identifiers.

6. Why Now: JISC Strategy • Middleware appears under Aim One: “To develop solutions that help the UK education and research communities to keep their activities world class through the use of ICT.” (1.4 a middleware service). • Meets Key Performance Indicator: “Develop a common, integrated information and communications environment.” • http://www.jisc.ac.uk/index.cfm?name=about_strategic.

7. Why Now: The AAA Programme July 2002: “to undertake a number of projects designed to give the UK experience of the emerging technologies in the authentication and authorisation area, based on open, vendor-independent standards.” An Audit.

8. Why Now: Developing the AAA Projects • Very briefly, technologies investigated: • AKENTI. • PERMIS. • CAS (Community Authorisation Service). • PAPI. • RADIUS. • SHIBBOLETH. • DIGITAL CERTIFICATE / PKI DEVELOPMENTS. • Supported By: • Study of Institutional Roles. • Policy Study.

9. Why Now: Current Technology • 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.

10. 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. • Full Support service for devolved management.

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

12. 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.

13. 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.

14. 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).

15. Developing for the future • Athens service continues to be offered and continues to be enhanced. • Robust technology and … • Robust service. • Future service for access management will go out for open tender as current service does.

16. 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

17. Core Middleware: Technology Development • 16 funded projects. • April 2004 – March 2007. • Investigating the development of middleware technology within key areas: • grid development, • PERMIS development, • portals development, • inter-institutional collaboration, • Shibboleth in non-University environments.

18. Core Middleware: Infrastructure • Building working Shibboleth Infrastructure within the UK. • ‘Shibbolising’ JISC resources. • Central services: WAYF, target support, origin support, policy development. • Early Adopters calls. • Athens gateway.

19. Key Concerns • Practical trials of the Shibboleth technology. • Policy Development. • Support for wireless development. • Roles / attribute management (PERMIS). • Needs of researchers. • Needs of FE. • Virtual Organisations.

20. Why this route? • Clearly identified NEED for new service from community. • Good international take-up of Shibboleth. • Shibboleth trials successful (AAA Programme) – proven to meet requirements. • Interest from Publishers. • Open standards.

21. What’s Coming Up? • Lots of development work from the development projects. • ‘Shibbolised’ JISC resources (EDINA, MIMAS). • Core Infrastructure development (including policy development). • Public discussion event. • “Early Adopters” calls for both institutions and resource owners. • “Assisted Take-up” services for origin (institution) and target (resource) sites.

22. Middleware Development: Timescale Timescales of Athens contract, development and Core Middleware Development.

23. Message • Access management requirements have changed. JISC is reacting to that (proven) change. • Looking several years down the line. • No change to current service (except improvements!). • Fully operational next generation access management system when it is needed.

24. Questions? Contacts: Nicole Harris, Programme Manager. n.harris@jisc.ac.uk. Alan Robiette Programme Director / Acting Head of Development. a.robiette@jisc.ac.uk.

25. How does it work?

26. 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