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

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.

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 1 Service Space 2 Gatekeeper Services Security Manager Security Manager

Verifying an incoming treaty A Treaty indicates what services and methods a service wants to use for a certain summit. 0 service getData foo bar … SecurityManager - Verify XML document - Compare treaty with permissions for the requesting service space - Set methods to authorized true/false service getData foo bar true getDataByFooAndBar

Verifying an execute method request service getDataByFooAndBar foo … 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.