The e-Demand ProjectThe e-Demand Project(A Demand-Led Service-Based Architecture for (A Demand-Led Service-Based Architecture for

Dependable e-Science Applications)Dependable e-Science Applications)

The e-Demand ProjectThe e-Demand Project(A Demand-Led Service-Based Architecture for (A Demand-Led Service-Based Architecture for

Dependable e-Science Applications)Dependable e-Science Applications)

Jie Xu (Project PI)A joint 3-year EPSRC/DTI-funded research project involving:

Universities of Durham, Leeds and NewcastleUniversities of Durham, Leeds and Newcastle

2

Project SummaryProject Summary

Funding Sources: DTI/EPSRC (THBB/008/00112C)Industrial Partners (Sun, Sharp and Sparkle Computer Technology)Total Grant - £636,900 (managed by NEReSC)

Duration: April 2002 - April 2005

Investigators:Jie Xu (Distributed Systems & Dependability, Leeds)Keith Bennett (Service-Based Architecture, SoE, Durham)Malcolm Munro & Nick Holliman (Visualisation, CS, Durham)

Research Staff:Paul Townend, Nik Looker, Erica Yang, and Stuart Charters

Hardware Testbed:A Sun 32 CPU UltraGrid computer connected to a network of Sun servers and workstations (e-Demand Laboratory) and to the White Rose Grid

3

ee-Demand:-Demand: A Software-BasedA Software-Based SolutionSolution

The Demand-Led Service-Based Architecture

- New service-based model for organising flexible Grid applications

- An instance of the service-based test architecture

Fault-Injection-Based Evaluation of Grid Middleware

- The FITMVS tool, supported by clusters of workstations

- Grid-FIT: Evaluation with respect to faults/attacks/performance

(The White Rose Grid Booth, see Nik Looker, Binka Gwynne)

Support for Dependable e-Science Applications

- Instance-Level Authentication and Identity Management & Attack-

Tolerant Information Service – ATIR (Dacheng Zhang &

Dr. Erica Yang)

- FT-Grid: Topologically-Aware Fault Tolerance (Paul Townend)

- 3D visualisation service for e-Science Applications (Stuart Charters)

4

Service-based ArchitectureService-based Architecture

The architecture that we started with:

Service consumerContractor/assembly

service providerCatalogue/ontology

provider

Demand

Provision

Finding

Service/solutionprovider

Ultra-late binding Publishing

e-Action service

Attack-tolerance service

3D visualization service

…

5

external WS architecture

middleware

internal service

internalservice

internal WS architecture

internal WS architecture

WS interface

access to internal systems

Web Services ArchitectureWeb Services Architecture

6

Service Description, Discovery and Service Description, Discovery and InteractionsInteractions

Description Discovery Interactions

properties & semantics

business protocols

interface

common base language

middleware properties

protocol infrastructure

basic & secure messaging

transportXML

WSDL

WSCLBPEL

QoScost

Directo

ries

UDDI HTTP

SOAP-messaging

WS-coordination

WS-transaction

7

Run-Time Checking & MonitoringSession Control & Management

Security Enforcement

• Authorisation of actions Role/Task-based Access Control Policy Management

• Authentication Identity management Non-repudiation etc

ExecutionEnvironment

Workflow/Session Management

Service CompositionInformation Integration

Grid-based resources(Built on the UK NGS/ White Rose Grid)

System Architecture for e-DemandSystem Architecture for e-Demand

Service 1 Service 2 Service 3

Service Instances Interactions

Message Encrypt/Decrypt

Traffic Monitoring & Filtering

ATIRFT-GridGrid-FIT

8

Testing Architecture: Grid-FITTesting Architecture: Grid-FIT

Our testing service currently implements network level fault injection.

Fault/Attack Injector(testing service)

Client

Server

ServiceRequest (may contain faults)

Response (may contain faults)

Middleware boundary

Interceptedrequest

Interceptedresponse

Potentiallyaltered

request

Potentiallyaltered response

9

Securing Instance-Level InteractionsSecuring Instance-Level Interactions

A complex Web service business session may span diverse security domains and organisational boundaries

Independent authentication and authorisation mechanisms are often needed to protect Web service business sessions from malicious attacks

These authentication and authorization mechanisms must work at the service instance-level

Suppose that three instances, Consumer, Producer, Shipper, compose a session

Shipper is unknown to Consumer as it is selected by Producer at run time

Based on a certificate from the business authority, Consumer then accepts that Shipper is a legal corporation/entity

Consumer also wants to be sure that Shipper is the assigned instance processing the order

Potential solutions

10

Service Instance IdentificationService Instance Identification

Two key technical issues to address:1) The Web service instances within a session have to be

identified ID-based solution Using instance identifiers to explicitly identify Web service

instances Suitable for fine-grained management mechanisms which can

exercise more precise control over a business session

Token-based solution Using correlation information to identify the

conversation/interactions amongst service instances and then implicitly identify the instances involved

Suitable for coarse-grained management mechanisms with less implementation overload

2) How to generate, distribute, and manage the security keys for enforcing the security boundaries of a business session –

so as to achieve effective attack/damage confinement

11

Various key management solutions have been considered and examined All participating instances within a given session share a

security key Group communication-based approaches Public key-based solutions (can be combined with ID-

based schemes for instance identification)

Business Session Key ManagementBusiness Session Key Management

Our Instance ID authenticator protocol is an ID-based schemeUsing the Diffie-Hellman protocol to distribute authentication information amongst participating instances of a sessionProviding authentication to Web service instances of the same session by appending the MAC code to the sending messages

12

System Evaluation: ExamplesSystem Evaluation: Examples

0

100000

200000

300000

400000

0 300 600 900 1200 1500 1800 2100

I nstance(s)

Mill

i-se

cond

(s)

512-bi ti denti fi er

1308821030

32617

43232

6215071242

0

10000

20000

30000

40000

50000

60000

70000

80000

0 300 600 900 1200 1500 1800 2100

I nstance(s)

Milli-second(s)

0

50000

100000

150000

200000

250000

300000

(1500 i nstances)

Si mpl eSessi onHandl er

Hada and Maruyama' sSol ut i on

Our Sol ut i on

Token-based scheme

ID-based scheme Scalability

Model

ScalabilityModel

13

Conclusions (1)Conclusions (1)

The e-Demand project is multi-faceted – it’s looking at service-based architectures, security, testing and fault tolerance.

The main focus of my talk has been to present some results from the e-Demand project in regard to architectures and instance-level interactions.

Important information about Grid-FIT, FT-Grid and ATIR etc can be found in the conf. proceedings.

Some Grid applications have been supported by the e-Demand architecture and services.

Experience with supporting interactions across organisational boundaries

14

Conclusions (2)Conclusions (2)

We have designed and implemented a fairly efficient system that supports dependable instance-level interactions, independent of the underlying Grid systems used

To further enhance the dependability of Grid applications, we have developed mechanisms and services for fault/attack detection and tolerance

We have focussed on assessing the dependability of Grid mechanisms and systems based on fault/attack injection techniques

15

The Way ForwardThe Way Forward

Continuous collaboration with NEReSC, the GOLD team, and the GT4 team etc

Wider range of Grid connections for larger scale experiments and assessments – the White Rose Grid, the CoLab Gird between UK and China etc

Grid applications in e-Social science domains (the MoSeS project)

Evaluation with a focus on performance and security