DSpace at VNU: Securing data in composite web services

The proposed approach makes sure that when the data is sent out from the composite service appropriate security policies will be applied.. To protect data when being sent between serv

Trang 1

Securing Data in Composite Web Services

Hieu Dinh Vo Dung Chi Phung Vu Quang Dung Viet-Ha Nguyen

University of Engineering and Technology Vietnam National University, Hanoi {hieuvd, dungpc, dungvq, hanv}@vnu.edu.vn

Abstract

Service-oriented architecture (SOA) provides a

solution for building information systems with

reusability, flexibility, and extensibility In SOA, new

services can be developed by using existing services

BPEL is considered as the main means for composing

services In service composition, a composite service

may be built from element services which belong to

different administrative domains Therefore, in order

to exploit the benefits of service composition, we must

carefully consider security issues One of them is to

protect users’ information In this paper, we describe

an approach for securing BPEL composite Web

services We assume that some users’ data received by

the composite services needs securing The proposed

approach makes sure that when the data is sent out

from the composite service appropriate security

policies will be applied

1 Introduction

Service-oriented Architecture (SOA) is an

architecture style for building information systems

with flexibility, reusability, and extensibility The core

element of SOA is services Services in SOA can be

considered as functions or operations available across

networks Services can be composed together to form

new Web services The new services are called

composite services meanwhile the composed services

are mentioned as element services

Based on XML and a set of other standards, Web

service is considered as the main technology for

implementing SOA Web Service Business Process

Execution Language (WS-BPEL, or BPEL) is an

XML-based language for service composition [1]

interactions between services may be carried out through insecure networks This raises the consideration of the security problems However, in order to keep the language from complexity, the designers of BPEL did not take security into account when developing the language Many researches have been done for filling the gap These works can be divided into two main directions: 1) composition of security policies [2, 3]; 2) protecting users’ data [4-6] Our research is an addition to the second direction

To protect data when being sent between services, composite service developers may use Transport Layer Security Protocol (SSL/TLS) [7] This protocol provides communication channel authentication, message confidentiality and integrity However, with this protocol, the protection is applied to all messages which are sent between services This may not be necessary in some cases (e.g messages do not contain confidential data) and therefore wastes computation In addition, SSL/TLS cannot protect data after being delivered to receivers In Web service systems, there are cases in which a Web service A receives a message, processes a part of the message, leaves other parts intact, and forwards the message to another Web service B for further processing With SSL/TLS, we cannot prevent service A from reading the whole message including parts that should be read by only B WS-Security [8] is an alternative which provides end-to-end security With WS-Security, we can both protect data on the wire and solve the mentioned issue However, there are several problems with applying WS-Security to BPEL services Firstly, WS-Security provides security at SOAP message level; therefore,

we need intermediate steps when applying to BPEL services In addition, upon receiving data, composite Web services may pass the data to its element services

2012 Fourth International Conference on Knowledge and Systems Engineering

Trang 2

approach for protecting data is to attach security policy

with data and requiring composite web services respect

the policy However, the question is how we can help

composite service developers to enforce security

accurately

This paper presents our in progress work on

proposing an approach for protecting data in composite

Web services built using BPEL The approach allows

composite service developers specify protection

mechanisms for received data and ensure that when

data is sent out, it will be applied declared protection

mechanisms

The remainder of the paper is organized as follows

The next section is about a motivating example In this

example, we use a process to illustrate the use of BPEL

and analyze security issues Section 3 presents our

approach for providing security for BPEL processes

Section 4 discusses the proposed approach and reviews

related works

2 Motivating Example

The motivating example we use in this paper is the

Purchase Order (PO) process (Fig 1) This process is

introduced in BPEL standard provided by OASIS [1]

Main steps of the process include receiving purchase

orders from customers, calculating the final prices,

selecting shippers and scheduling the production

process On finishing these activities, the process sends

invoices back to customers Purchase Order process is

a composite process written using BPEL Three

element services are Invoicing Service, Shipping

Service, and Scheduling Service

Figure 1 Information flow in PO process

In this process, information of a customer (included

in a variable named PO) is sent from the customer to

PO process This process then sends the information to Invoicing Service and Scheduling Service Although

the variable PO is not used for interactions between PO

process and Shipping Service, the information is also passed from PO Process to Shipping Service via the

variable shippingRequest

In the original version of PO process, there is no mention of secrecy of customer information In this paper, we assume that customer information is sensible (for example, containing credit card number and security code) and must be protected when being sent between Web services To achieve this, there should be

an agreement between PO process and the client Now

we assume that the PO process promises the client that

“information received from client must be encrypted before sending” To realize this agreement, PO

process’ developers must find some way for encrypting

variable PO before sending to other services It is

obvious that customer information is protected when being sent to Invoicing Service and Shipping Service However, there will be situations that the information

stored in variable PO is copied to another variable (in this example, shippingRequest) and sent out (to

Scheduling Service) In this case, the variable

shippingRequest must be also encrypted because it

contains customer information (copied from variable

PO) The developers of composite services can track

the flow of information in the services and specify corresponding security policy However, doing that will be tedious and, more important, error-prone In the next section, we propose an approach for helping developers to define and enforce security policy for data in composite services

3 Securing Data in Composite Services

This section presents our approach for securing data in composite Web services implemented using BPEL In our approach, we assume that there is a mechanism for client and service to negotiate security policies We only focus on the next step: the composite service developers realize the policy At this point, we only consider confidentiality and integrity of data The next section gives an overview of the architecture of the approach The section 3.2 and 3.3 describe the format for security policies The approach for deciding data need protecting is presented in section 3.4

3.1 Proposed Architecture

The architecture of our framework can be briefly described in Fig 2 There are four main components in the framework

Trang 3

BPEL-level Policy: the security policy defined by

composite service developers This policy is

considered as BPEL-level because BPEL notions such

as partnerLink are used to point out the data that we

should protect

Runtime Policies: the policies generated by Data

Flow Tracker; based on the BPEL-level security

policies

Figure 2 Architecture of the framework

Data Flow Tracker: takes BPEL-level policies as

input, updates policies, and produces runtime policies

Policy Enforcer: ensures that all SOAP messages

sent out conform to security policy

Policy Enforcer provides the enforcement based on

WS-Security This component will not be discussed

further in this paper In the following sections, we

provide more details of BPEL-level security policy,

runtime policies, and generation of runtime policies

(i.e the Data Flow Tracker)

3.2 Specifying BPEL-level Policies

From the agreement “information received from

client must be encrypted before sending”, the PO

process developers must define corresponding

BPEL-level security policy in order to realize that statement

A BPEL-level policy includes two parts: the methods

for protecting data and the indication of what data is

protected by which method The listing below (Listing

1) gives an example for a security policy protecting

data in PO process

<method id=sign1>

</SignatureMethod>

CN=ABC,OU=DSE,O=UET,L=Hanoi City, ST=HN,C=VN </X509SubjectName>

DMGFDHJXgAwI9kd9Ze37HDUEIBOPS [lines omitted for brevity]

</X509Certificate>

</X509Data>

</KeyInfo>

</method>

<method id=encrypt1>

<action>encrypt</action>

</EncryptionMethod>

</method>

<policy>

<data>

//purchasing/purchaseOrderPT/sendPurchaseOrder/PO Message

</data>

<method> encrypt1 </method>

</protect>

</policy>

Listing 1 An example of BPEL-level security

policy

The data element in the policy indicates the point where data is received The value of this element has

format //partnerlink/portType/operation/parameter In

the example, the indicated data will be protected is

//purchasing/purchaseOrderPT/

sendPurchaseOrder/POMessage This means that at runtime any data received via variable POMessage at

operation sendPurchaseOrder of portType purcahseOrderPT of partner link purchasing will be

protected by the corresponding security method In our

case, variable PO is used at the place of POMessage,

therefore, the data in this variable will be protected In case the data is copied to other variables, these variable

are also applied the same security policy

3.3 Runtime Policies

Runtime policies are generated during the execution of BPEL process While BPEL-level policies are the same for any execution of a BPEL process, runtime policies might be different These policies

Trang 4

depend on execution paths, which, in turn, depend on

inputs to the process

Runtime policies have the same format as

BPEL-level policies, which include method for protection and

data to protect The difference is that while in

BPEL-level policies we use parameters of portTypes as data,

in runtime policies we use variables

3.4 Generating Runtime Policies

This section describes the way Data Flow Tracker

tracks the flow of data and generates runtime policies

As mentioned in previous section, in the security

policy, users (i.e composite services’ developers) only

specify the input data (via

//partnerlink/portType/operation/parameter) During

the execution of the process, data may be copied to

other variables The framework tracks the data paths

and decides which data should be applied which

security policy

We use following functions to express the way

policies are updated

• protect(a,m): this means data a is protected by

the security method m These functions can be

extracted from BPEL-level policies At this

point, the security methods we are considering

include signing the data and encrypting

• P is the set of protect(x,y) for a BPEL process

• assign(a,b): means assign the value of a to

variable b

• condition(a,b): means a is considered as a

condition for some action on value of b We

need this function for handling implicit

information flow [9] An example of this kind

of flow is the statement if (a) then b=1 else

b=0 After this statement, we can infer the

value of a through b In BPEL, implicit

information flows may happen in <if>,

<while>, <repeatUntil>, and <forEach>

activities

• part(a,b): means b is a part of data a

When activities of BPEL process is carried out, the

policies are updated and applied to corresponding data

Listing 2 presents the updating of policies when an

assigning activity assign(a,b) is encountered

01: remove all statements protect(b,m) from P

02: if the statement protect(a,m) is in P then

03: add statement protect(b,m) into P

04: if the statement protect(c,m) is in P and part(c,a) then

05: add statement protect(b,m) into P

Listing 2 Updating security policies

Whatever stored in b before the assignment will be

erased; therefore previous security policy for b

becomes redundant and will be deleted (line 01) Lines

02 and 03 handle the case there is a statement that data

a is protected by method m Because the value of a will

be assigned to b, b is also need protecting using m Lines 04 and 05 process the case a is a part of c and c

is protected by m The consequence is b will be protected by m

If condition(a,b), there is an implicit flow from a to

b Therefore, we must protect b as what we do with a

In this case, the Listing 2 also can be used to update policies

4 Discussion and Relate work

In our approach, security policies are defined at BPEL level so it is more convenient for composite service developers They do not need to examine security for SOAP messages

There are several researches aiming at providing security for composite Web services A representative one is the work of Charfi and Mira Mezini [4] They proposed a framework based on the concept of aspects for securing composite Web services (developed using BPEL) Their framework exploits AO4BPEL - an aspect-oriented extension to BPEL The main idea is to insert security code (written in BPEL) in to some specific points in the process The framework includes three main components: deployment descriptor, security service, and process container Deployment descriptor contains security parameters such as usernames, passwords, and keys Security service is a Web service providing security functionalities such as encrypting and signing messages Process containers are generated based on deployment descriptor These containers enforce security for composite services by invoked functionalities of security service Process containers implemented as a set of AO4BPEL aspects Jinpeng and colleagues [6] proposes a fine-grain access policy specification for composite Web services In detail, the approach includes two parts: WS-SensFlow and SF-Guard The former is for defining access control policy while the latter is for enforcing the defined policy The authors claim that with this approach, we can prevent unauthorized Web service from accessing security-sensitive data However, the proposed architecture cannot prevent the case in which the business logic copies security-sensitive data from one variable to another but does not specifying and security policy for the latter In addition, the approach requires the client of Web services knows all Web services taking part in invocations This kind of information is difficult to achieve in case of service composition

Trang 5

Xu and colleagues [5] propose a framework for

protecting customer privacy The framework includes

five main components: service composition code,

service models, privacy policies, policy compliance

checker and obligation generation, and obligation

enforcer Before invoking a composite Web service, a

user will obtain the model of the service The policy

compliance checker (at user side) will inspect to see

whether the service model conforms to privacy policy

of the user In case the service model cannot satisfy the

privacy policy of the user, an obligation is generated

and during the execution of the composite service, the

obligation enforcer will ensure that composite service

respects privacy policy of the user Our work can be

considered as a complement to this work Our work

helps composite service developers in realizing privacy

policies

5 Summary

We propose a framework for securing data in

composite web services With our framework,

composite service developers specify security policy

for received data During the execution of BPEL

processes, security policies are updated and applied for

data before being sent

We are still working on the framework We are

focusing on a convenient approach for developers to

specify security policy (see Listing 1) such as using a

graphical user interface, and an approach for tracking

information flows We also considering the cases in

which security policies are attached with SOAP

messages [10] and these policies are used to updated

runtime policies

Acknowledgements

This work was financially supported by project CN.11.04

at UET, VNU The authors also thank the TRIG project at

VNU for providing the research environment

References

[1] OASIS Web Services Business Process

Execution Language version 2.0 2007;

Available from: http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html [2] Carminati, B., E Ferrari, and P.C.K Hung

Security Conscious Web Service Composition

in International Conference on Web Services,

2006 ICWS '06 2006

[3] Satoh, F and T Tokuda, Security Policy

Composition for Composite Web Services

IEEE Transactions on Services Computing,

2010 PP(99): p 1-14

[4] Anis, C and M Mira, Using Aspects for

Security Engineering of Web Service Compositions, in Proceedings of the IEEE International Conference on Web Services

2005, IEEE Computer Society

[5] Wei, X., et al., A Framework for Building

Privacy-Conscious Composite Web Services,

in Proceedings of the IEEE International Conference on Web Services 2006, IEEE

Computer Society

[6] Jinpeng, W., L Singaravelu, and C Pu

Guarding Sensitive Information Streams through the Jungle of Composite Web Services in Proceedings of IEEE International Conference on Web Services

2007

[7] Rescorla, T.D.a.E The Transport Layer

Security (TLS) Protocol 2008 July 2011];

Available from:

http://www.ietf.org/rfc/rfc5246.txt [8] OASIS Web Services Security 2006 July

2011]; Available from: http://docs.oasis-open.org/wss/v1.1/

[9] Denning, D.E and P.J Denning, Certification

of programs for secure information flow

Commun ACM, 1977 20(7): p 504-513

[10] OASIS WS-SecurityPolicy 1.2 2007 July

2011]; Available from: http://docs.oasis- open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html

Định dạng
Số trang	5
Dung lượng	168,6 KB