Supporting education and research Core Middleware Development Nicole Harris, Programme Manager, JISC Middleware Team.

Supporting education and research

Core Middleware Development

Nicole Harris, Programme Manager, JISC Middleware Team

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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. 

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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).

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 22

Middleware Development: Timescale

Jul-03 Jul-04 Jul-05 Jul-06 Jul-07 Jul-08Athens Service

Athens Development

CM: Development

CM: Infrastructure

Contract Neg

Early Adopters and Assisted Take-up

Embedding

Potential Service

Potential Service

Timescales of Athens contract, development and Core Middleware

Development.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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.

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 25

How does it work?

6 - 7 July 2004 Middleware Plenary, Joint Programmes Meeting 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