2012 Fourth International Conference on Knowledge and Systems Engineering 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 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 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 endto-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 for further processing These element services themselves may be composite services In this case, data is passed via different administrative domains An 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 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] In service composition, element services may belong to different administrative domains (i.e services belong to different organizations) and the 978-0-7695-4760-2/12 $26.00 © 2012 IEEE DOI 10.1109/KSE.2012.33 60 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 presents our approach for providing security for BPEL processes Section discusses the proposed approach and reviews related works 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 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 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 Figure Information flow in PO process The architecture of our framework can be briefly described in Fig There are four main components in the framework In this process, information of a customer (included in a variable named PO) is sent from the customer to 61 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 CN=ABC,OU=DSE,O=UET,L=Hanoi City, ST=HN,C=VN DMGFDHJXgAwI9kd9Ze37HDUEIBOPS [lines omitted for brevity] encrypt … //purchasing/purchaseOrderPT/sendPurchaseOrder/PO Message encrypt1 Figure 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) Listing 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.2 Specifying BPEL-level Policies From the agreement “information received from client must be encrypted before sending”, the PO process developers must define corresponding BPELlevel 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 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 sign 62 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 with a In this case, the Listing also can be used to update policies depend on execution paths, which, in turn, depend on inputs to the process Runtime policies have the same format as BPELlevel policies, which include method for protection and data to protect The difference is that while in BPELlevel 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 , , , and activities • part(a,b): means b is a part of data a Discussion and Relate work In our approach, security policies are defined at BPEL level so it is more convenient for composite service developers They 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 securitysensitive 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 When activities of BPEL process is carried out, the policies are updated and applied to corresponding data Listing 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 Updating security policies Whatever stored in b before the assignment will be erased; therefore previous security policy for b 63 References 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 [1] [2] [3] [4] Summary [5] 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 [6] [7] [8] 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 [9] [10] 64 OASIS Web Services Business Process Execution Language version 2.0 2007; Available from: http://docs.oasisopen.org/wsbpel/2.0/wsbpel-v2.0.html Carminati, B., E Ferrari, and P.C.K Hung Security Conscious Web Service Composition in International Conference on Web Services, 2006 ICWS '06 2006 Satoh, F and T Tokuda, Security Policy Composition for Composite Web Services IEEE Transactions on Services Computing, 2010 PP(99): p 1-14 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 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 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 Rescorla, T.D.a.E The Transport Layer Security (TLS) Protocol 2008 July 2011]; Available from: http://www.ietf.org/rfc/rfc5246.txt OASIS Web Services Security 2006 July 2011]; Available from: http://docs.oasisopen.org/wss/v1.1/ Denning, D.E and P.J Denning, Certification of programs for secure information flow Commun ACM, 1977 20(7): p 504-513 OASIS WS-SecurityPolicy 1.2 2007 July 2011]; Available from: http://docs.oasisopen.org/ws-sx/ws-securitypolicy/200702/wssecuritypolicy-1.2-spec-os.html ... 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... Purchase Order process is a composite process written using BPEL Three element services are Invoicing Service, Shipping Service, and Scheduling Service Securing Data in Composite Services This section... 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