Regulating the Synchronous Interaction of Web-Services

1. Regulating the SynchronousInteraction of Web-Services Constantin Serban Department of Computer Science Rutgers University 1

2. Outline • Enterprise-wide access control : motivation • Current approaches and LGI-based solution • Regulating synchronous communication • Controlling the request arguments • Controlling the answer • Conclusions 2

3. Enterprise-wide access control • Enterprises increasingly rely on heterogeneous collections of web services • Each WS may have its own server-centric policy • Question: how does one establish a communal, enterprise wide policy? • How to ensure that this policy is complied with 3

4. Enterprise wide access control Enterprise policy WS WS 4

5. Communal AC –a Case Study • Consider a healthcare system composed of multipleheterogeneous services maintaining patient records. • An example of a communal AC policy: • Doctors can access patient records, in full. • Researchers can access specified parts of the records, and they have to pay for it, in proportion to the volume of data received. • All accesses to patient records are to be monitored. • Such a policy has to be specified at the enterprise level, and complied with by all WS and their users 5

6. Server-Centric AC Client Access Control Request Server Response 6

7. Server-Centric AC • Each server has its own AC policy • The enforcement of the policy is at the discretion of the server Client Access Control Request Server Response 7

8. Communal AC (XACML & Others) P PDP: Policy Decision Point PDP PEP: Policy Enforcement Point Client PEP Request Server Response 8

9. Communal AC (XACML & Others) • The policy can be enterprise wide • But the enforcement is still at the discretion of the server • Moreover, it is application-dependent P PDP: Policy Decision Point PDP PEP: Policy Enforcement Point Client PEP Request Server Response 9

10. Communal ACvia central Reference Monitor (RM) • Carries enterprise-wide policy • Access control is mandatory Client Request P Server Response RM 10

11. Communal AC via central RM • Not scalable, and potential bottleneck Client Request P Server Response RM Client Client Server 11

12. Communal AC via LGI Client Req P P Server Resp Controller Controller 12

13. Communal AC via LGI • Both controllers carry the same policy • Access control is mandatory, stateful, fine-grained Client Req P P Server Resp Controller Controller 13

14. Types of communication in WS • Regulation of message exchange using LGI (previous presentation) • Significant portion of WS traffic is synchronous (SOAP-RPC) • Regulation of synchronous communication has several peculiar aspects 14

15. Outline • Enterprise-wide access control : motivation • Current approaches and LGI-based solution • Regulating synchronous communication • Controlling the request arguments • Controlling the answer • Conclusions 15

16. Regulating synchronous communication • Control both therequestand the response • Regulate both at the client side and at the server side—maintaining state in both • Sensitive to: • Request arguments • Return value • State, of both client and server; state of the communication between the request and the response • Impose constraints on the communication protocol: time-outs, load balancing, etc 16

17. Control over the request • Purpose • Specify under what condition a client can make a certain request to a service • different than what client can access the service • Access control based on: • Source and target of the request, their state, the request and its parameters 17

18. Control over the response • Control information might be available only at the time of the response • The state of both the client and the server are best updated based on response data • For other purposes: auditing, accounting, etc. 18

19. Response control : Example 1 • A healthcare system provides a generic service to access a patient’s record. • Clients can be both doctors and researchers • Doctors can access each record in full, researches can access some of the information within a record • Access control scheme can blackout the sensitive data in a record after the service responds. 19

20. Response Example 1(cont’d) Controller Controller Client getRecord(id#) P P Server recordAns ------- ------- diagnostic medication recordAns ssn name diagnostic medication 20

21. Response control : Example 2 • Researchers pay only if a request is satisfied, and in proportion to the volume of the data received • Update the state (token, others…) of the researcher only if the request was successful • Increase/decrease the reputation of the server • The answer itself determines the change in the state of (either, both) server/client 21

22. Response Example 2(cont’d) Controller Controller Client getRecord(id#) P P Server recordAns decreaseBudget updateReputation 22

23. Implementation • RRMI – Regulated RMI : source level RMI compatible • Full stub/skeleton generation • RRMI Registry fully implemented with LGI control • Policies written in Java in a simple, concise form. • Good performance : overhead in the order of few hundreds of micro-s/method call • Part of a subsequent release of the Moses platform • Work in progress: move the protocol to SOAP 23

24. Summary • WS are required to comply to enterprise-wide policies • Several approaches in access control • LGI control model for WS • Synchronous interaction of WS • Stateful and fine grained control • Control over the reply in synchronous interaction 24