Supporting education and research Core Middleware Development Nicole Harris, Programme Manager, JISC...
-
Upload
gabrielle-bolton -
Category
Documents
-
view
218 -
download
1
Transcript of Supporting education and research Core Middleware Development Nicole Harris, Programme Manager, JISC...
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. [email protected].
Alan Robiette Programme Director / Acting Head of Development.
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