Download Regulating the Synchronous Interaction of Web-Services

Regulating the Synchronous
Interaction of Web-Services
Constantin Serban
Department of Computer Science
Rutgers University
1
Outline
• Enterprise-wide access control : motivation
• Current approaches and LGI-based solution
• Regulating synchronous communication
– Controlling the request arguments
– Controlling the answer
• Conclusions
2
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
Enterprise wide access control
Enterprise policy
WS
WS
4
Communal AC –a Case Study
• Consider a healthcare system composed of
multiple heterogeneous 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
Server-Centric AC
Client
Request
Response
Access Server
Control
6
Server-Centric AC
Client
Request
Response
Access Server
Control
• Each server has its own AC policy
• The enforcement of the policy is at the
discretion of the server
7
Communal AC
(XACML & Others)
P
PDP: Policy Decision Point
PEP: Policy Enforcement Point
Client
Request
PDP
PEP
Server
Response
8
Communal AC
(XACML & Others)
P
PDP: Policy Decision Point
PEP: Policy Enforcement Point
Client
Request
PDP
PEP
Server
Response
• The policy can be enterprise wide
• But the enforcement is still at the discretion of the server
• Moreover, it is application-dependent
9
Communal AC
via central Reference Monitor (RM)
Request
Client
P
Server
Response RM
• Carries enterprise-wide policy
• Access control is mandatory
10
Communal AC via central RM
Request
Client
P
Server
Response RM
Client
Client
Server
• Not scalable, and potential bottleneck
11
Communal AC via LGI
Client
P
Req
P
Server
Resp
Controller
Controller
12
Communal AC via LGI
Client
P
Req
P
Server
Resp
Controller
Controller
• Both controllers carry the same policy
• Access control is mandatory, stateful,
fine-grained
13
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
Outline
• Enterprise-wide access control : motivation
• Current approaches and LGI-based solution
• Regulating synchronous communication
– Controlling the request arguments
– Controlling the answer
• Conclusions
15
Regulating synchronous
communication
• Control both the request and 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
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
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
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
Response Example 1(cont’d)
Controller
Client
P
Controller
P
recordAns
------------diagnostic
medication
getRecord(id#)
Server
recordAns
ssn
name
diagnostic
medication
20
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
Response Example 2(cont’d)
Controller
Client
P
Controller
P
getRecord(id#)
Server
recordAns
decreaseBudget
updateReputation
22
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
Summary
• WS are required to comply to enterprisewide 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