Decentralized Information Spaces for Composition and Unification of

Services (DISCUS) Successor to OzWeb Builds on WebServices (Relatively) Static Service Spaces Dynamic Summits Gatekeepers impose Treaties as to

whether/how Summits can use Service Space services

Workflow coordinates services

C2 C3

C1

A1

A3

A2

B3

B2B1

GK-A

GK-B

GK-C

A2

B2

C1

TREATYOperations

1. Method1 ()2. Method2 ()Parameters

Accesspartial/complete

InfoExchange/

servicecomposition

10101010101010

1101

0110

1010101110

Trust Management

Service Space - C

Service Space - B

Service Space - A

Policy Management

Ctxt,extnt ... ...... Complete ... ...... Defcon Mo-op Partial... ... ...

Service-SpaceMethods

Summit[Habitat]

Access = F(Context, Credentials)

DISCUS Gatekeeper Overview

The Gatekeeper exists at the boundary of a service space facilitating secured access to the logical collection of web services comprising the service space.

It is the single point of interaction between the outside world and the service space.

Its purpose is to regulate access to web services implemented using heterogeneous programming languages, hosted on heterogeneous platforms.

Gatekeeper Features

Dynamic composition of service spaces requires the Gatekeeper to have a runtime mechanism for interacting with arbitrary web services – Runtime Web Service Proxy Generation.

The Gatekeeper “discovers” the details of expected inputs – parameter types – at runtime via the use of reflection on the Web Service Proxy it generates.

Control Flow of Solution – Part I

Eapp talks to its local Gatekeeper, GK1, saying “Hey, I need to use service X of SS2” – This message is expressed in the form of an Alpha-Protocol (a simple workflow) which Eapp will pass to GK1.

GK1 takes the Alpha-Protocol and goes out to find the Gatekeeper of service space 2, GK2

GK1 then sends a (signed) treaty request to GK2 requesting use of service X. The signature authenticates GK1.

Control Flow of Solution – Part II

GK2 verifies the (signed) treaty request and based on service space’s 2 security policy decides whether to allow GK1 to use service X. GK2 sends back a filled Treaty which contains authorization data.

Once GK1 has permission to use service X, it issues an ExecuteServiceMethodRequest forwarding the input from Eapp onto GK2 that then acts as an execution proxy to service X.

Control Flow of Solution – Part III

GK2 verifies GK1’s Execution Request, contacts service X forwarding the input from GK1.

GK2 receives the output of the operation, signs it and sends it back to GK1

GK1 verifies the (signed) results and passes these back to Eapp.

Service Discovery

TreatyMaker

Registry

Gate Keeper

Active Summit

Gate Keeper

TreatyMaker

Registry

Data

Legacy Systems

Service-Space

Access toRemote

Services viaGate Keeper

Request forServicessent via

Gate Keeper

Response toservice

request viaGate Keeper

WFManager

Treatiesdecide the

behaviour ofServices -Partial orComplete

DISCUS Security overview

Multiple service spaces Each offers different services Services used together in summits

to resolve problems Different services have different

security levels/requirements Have to control access by external

service spaces

Two main requirements

Authentication Can’t do anything without knowing who

is really asking for a service Services Spaces authenticated by

unique public key Authorization

A service space can only call certain service methods

Each service space has a security matrix that defines the permissions

Implementation overview

• Service spaces communicate only through the Gatekeepers

• The Gatekeeper uses the Security Manager to:

• sign and verify messages• create and verify treaties• verify execute method requests

Service space 1Service space 1

Service Space 2

Gatekeeper

Gatekeeper

Services

Services

SecurityManager

SecurityManager

Verifying an incoming treaty

A Treaty indicates what services and methods a service wants to use for a certain summit.

<Treaty> <TreatyID>0</TreatyID><ServiceInfo> <ServiceName>service</ServiceName> <ServiceMethod> <MethodName>getData</MethodName> <Parameter>foo</Parameter> <Parameter>bar</Parameter> </ServiceMethod></ServiceInfo></Treaty><ds:Signature>…</ds:Signature>

SecurityManager

- Verify XML document- Compare treaty with permissions for the requesting service space- Set methods to authorized true/false

<Treaty> <TreatyID>234989592</TreatyID><ServiceInfo> <ServiceName>service</ServiceName> <ServiceMethod> <MethodName>getData</MethodName> <Parameter>foo</Parameter> <Parameter>bar</Parameter> <Authorized>true</Authorized> <MethodImplementation>

getDataByFooAndBar </MethodImplementation> </ServiceMethod></ServiceInfo></Treaty>

Verifying an execute method request

<ExecServiceMethodRequest> <TreatyID>234989592</TreatyID> <ServiceName>service</ServiceName> <MethodName>

getDataByFooAndBar </MethodName> <Parameter>foo</Parameter></ExecServiceMethodRequest><ds:Signature>…</ds:Signature>

SecurityManager

- Verify XML document- Get treaty from database- Compare method request with methods in treaty- Return OK, or error message

Error: number of parameters does not match treaty.

An execute method request is sent when a service space wants to call a certain method on a service.