Validating Orchestration of Web Services with ... - Semantic Scholar

Download PDF
1 downloads 5622 Views 357KB Size Report
Comment
May 17, 2007 - Service orchestration. We address a recent cryptographic tool, aggre- gate signatures, to validate the orchestration by requiring all partners.
Validating Orchestration of Web Services with BPEL and Aggregate Signatures ∗ Carlo Blundo † Clemente Galdi

§

Emiliano De Cristofaro ‡ Giuseppe Persiano ¶

May 17, 2007

Abstract In this paper, we present a framework providing integrity and authentication for secure workflow computation based on BPEL Web Service orchestration. We address a recent cryptographic tool, aggregate signatures, to validate the orchestration by requiring all partners to sign the result of computation. Security operations are performed during the orchestration and require no change in the services implementation.

1

Introduction

Web Services technology [12] provides software developers with a wide range of tools and models to produce innovative distributed applications. Interoperability, cross platform communication, and language independence are only a part of the appealing characteristics of Web Services. The standardization and the flexibility introduced by Web services in the development of new applications translate into increased productivity and gained efficiency. Furthermore, the challenges of fast growing and fast evolving business processes lead to a higher level of interactions and to the need of applications integration across organizational boundaries. Services are no longer designed ∗

This work has been partially supported by the European Commission through the IST program under contracts FP6-1596 (AEOLUS). † Dipartimento Informatica ed Applicazioni - Universit`a di Salerno - [email protected] ‡ Dipartimento Informatica ed Applicazioni - Universit`a di Salerno - [email protected] § Dipartimento di Scienze Fisiche - Universit`a di Napoli Federico II - [email protected] ¶ Dipartimento Informatica ed Applicazioni - Universit`a di Salerno - [email protected]

as isolated processes, but to be invoked by other services and to invoke themselves other services. This paradigm is often referred to as Service-Oriented Computing (SOC) [27]. Two different approaches can be considered: service orchestrations, i.e., there is one particular service that directs the logical order of all other services, and service choreographies, i.e., individual services work together in a loosely coupled network [24]. Interactions should be driven by explicit process models. Therefore, the need of languages to model business process arises in particular for processes implemented by Web Services. Recently, many languages have been proposed, such as BPML [17], XLANG [11], WSCI [10], WS-BPEL [22], WSCDL [9]. Among these, the Business Process Execution Language for Web Services (WS-BPEL) has emerged as the de-facto standard for “enabling users to describe business process activities as Web services and define how they can be connected to accomplish specific tasks” [22]. However, whereas security and access control policies for normal Web Services are well studied, Web Services composition still lacks a standard tool to validate the orchestration of processes, in terms of providing integrity and authenticity of the computation. In this paper, we refer to the standard tool for providing integrity and authentication in network interactions, i.e., cryptographic signatures. However, two different issues should be considered when addressing this tool to provide security within Web Services interactions. First, the number of signatures would grow linearly to the number of users and processes, arising issues related to the size of certificate chains and bandwidth overhead. Second, there could be applications requiring a specific order to perform processes. To this aim, we address a recent cryptographic tool, aggregate signatures, first presented by Boneh et al. [15]. Aggregate signatures allow to aggregate multiple signatures on distinct messages into a single short signature. Furthermore, we consider a variant of this primitive, in which the set of signers is ordered. This scheme is referred to as sequential aggregate signatures and it has been presented by Lysyankaya et al.[25]. In this paper, we present a framework which uses these two schemes to validate Web Services orchestration, by requiring each partner to sign the result of its computation. In particular, since Web Services interactions can either be performed in parallel or sequentially, we need both schemes: when the computation is carried out in parallel, we use the “standard” aggregate signature scheme presented in [15] and its sequential variant presented in [25] to validate sequential workflow computation. The rest of the paper is structured as follows. In Section 2, we give an overview of the endorsed technologies, while in Section 3 we present our framework.

2 2.1

Background Workflow and WS-BPEL

A workflow describes the automation of a business process. During the process documents, information, or roles are exchanged among actors in order to complete a task as specified by a well-defined set of rules. In other words, a workflow is composed by a set of tasks, related to each other through different types of relationships [20]. A workflow management system allows to define, create, and manage the execution of a workflow through a software executing on one or more workflow engines. A workflow manager interpreters the formal definition of a process, in order to interact with several actors by managing states and tasks coordination. Tasks, actors, and processes within the workflow can be designed as desired. In this paper, we focus on the Web Service technology and on WSBPEL, the Business Process Execution Language for Web Services. For a thorough overview of Web Services, we refer to [21]. WS-BPEL is an XMLbased language for describing the behavior of business process based on Web Services [22]. It provides activities, which can be either basic or structured. A basic activity can communicate with the partners by messages (invoke, receive, reply), manipulate data (assign), wait for some time (wait), do nothing (empty), signal faults (throw), or end the entire process (terminate). A structured activity defines a causal order on the basic activities and can be nested in another structured activity itself. The structured activities include sequential execution (sequence), parallel execution (flow), data-dependent branching (switch), timeout-or message-dependent branching (pick), and repeated execution (while). The most important structured activity is a scope. It links an activity to a transaction management and provides fault, compensation, and event handling. A process is the outmost scope of the described business process. For more details about BPEL, we refer to [28], [19], and [23]. WS-BPEL is a standard specification, therefore it must be implemented. Nowadays, many implementations are available, such as Bexee [3], Oracle BPEL Process Manager [6], BPEL Maestro [7], or iGrafx [5]. Among these, the ActiveBPEL implementation [2] appears to be one of the most interesting solutions, as being open source and freely available. ActiveBPEL is deployed as a servlet into Apache’s Jakarta Tomcat container. It has extensive documentation and has been released by Active EndPoints into the public domain under a Lesser Gnu Public License. It provides a full implementation of the BPEL 1.1 specification. Moreover, Active EndPoints released two useful

and powerful tools: ActiveBPEL Designer and ActiveBPEL Enterprise. The former is a comprehensive visual tool for creating, testing, and deploying composite applications based on BPEL standard, and it is a plug-in to the Eclipse development environment [4]. The latter is a complete BPEL engine, which provides many features to administrate BPEL processes.

2.2

Aggregate Signatures

An aggregate signature scheme is a digital signature that supports aggregation. Given n signatures on n distinct messages from n distinct users, it is possible to aggregate all these signatures into a single short signature. For the rest of the paper, we will use the acronym AS to refer to the signature scheme presented in [15]. Let U be the set of possible users. Each user u ∈ U holds a keypair (P Ku , SKu ). Consider a subset U ⊆ U. Each user u ∈ U signs a message Mu obtaining σu . All the signatures are combined by an aggregating party into a single aggregate σ, whose length is equal to any of the σu . The aggregating party has not to be one of the users in U, neither it has to be trusted by them. The aggregating party needs to know to the users’ public keys, the messages, and the signatures on them, but not any private keys. This scheme allows a verifier, given σ, the identities of the users, and the messages, to check whether each user signed his respective message. The AS scheme is based on Co-gap Diffie-Hellman signatures (for details, see [16]) and bilinear maps and it is proved to be secure in a model that gives the adversary the choice of public keys and message to force. Authors added the constraint that an aggregate signature is valid only if it is an aggregation of signatures on distinct messages. However, in [13] a new analysis and proof is provided to overcome this limitation, yielding the first truly unrestricted aggregate signature scheme. Moreover, a sequential aggregate signature scheme has been proposed in [25]. For the rest of the paper, we refer to it as SAS. In this scheme, the set of signers is ordered. The aggregate signature is computed by having each signer, in turn, add his signature to it. The construction proposed in [25] is based on families of certified trapdoor permutations. In the same paper the authors explicitly instantiate the proposed scheme based on RSA. This scheme is based on the the full-domain hash signature scheme introduced in [14]. Such a scheme works with any trapdoor one-way permutation family. However, also this scheme is affected by the restriction that distinct signers have to sign distinct messages. Once again, in [13] a new analysis and proof has been showed that the restriction can also be dropped, yielding an unrestricted sequential aggregate signature scheme. The main difference with sequential aggregate signatures is that each

signer transforms a sequential aggregate into another that includes a signature on a message of his choice. Signing and aggregation are a single operation; sequential aggregates are built in layers: the first signature in the aggregate is the inmost. As with non-sequential aggregate signatures, the resulting sequential aggregate is the same length as an ordinary signature. Such a scheme is proved secure in the random oracle model.

2.3

WS-Security

In the context of Web Services, many supplemental standards for guaranteeing security features have been released in the last years, and collected under the WS-Security specification [26]. This specification (whose last version has been released at the beginning of the 2006) is the result of the OASIS Technical Committee’s work [1]. It proposes a standard set of SOAP extensions that can be used when building secure Web services to provide confidentiality (messages should be read only by sender and receiver), integrity and authentication (the receiver should be guaranteed that the message is the one sent by the sender and has not been altered), non repudiation (the sender should not be able to deny the sending of the message), and compatibility (messages should be processed according to the same roles by any node on the path message). Such mechanisms provide a building block that can be used in conjunction with other Web service extensions and higher-level applications to accommodate a wide variety of security models and security technologies. Before the release of the WS-Security standard, such features had to be implemented by adding and managing customized ad-hoc headers in SOAP messages exchanged during Web Services interactions. Instead, within WSSecurity these headers become standard as well as mechanisms to manage them. In fact, WS-Security implementations provide application developers with dedicated handlers to process security information in a transparent way.

3

Our framework

Our goal is to build a framework which provides integrity and authentication for secure workflow computation based on BPEL Web Service orchestration. In our scenario, the orchestrator defines the workflow and describes Web Services composition through BPEL. We want to ensure that: 1. The workflow has been correctly followed by the defined partners. 2. The workflow has been correctly followed in the defined order.

3. The partners cannot repudiate their computation. 4. The partners can verify that their computation has been correctly inserted into the workflow.

Figure 1: Combination of SAS and AS schemes

aggSi gn seqAggSi gn addToken

Figure 2: Framework Architecture To this aim, we address to the aggregate signature schemes presented in Section 2, and referred to as AS and SAS. We hereby propose a novel aggregate signature scheme as the combination of the AS scheme in [15] and the SAS scheme in [25]. Actually, we need both schemes since composite Web Services execution can be performed either in a parallel or in a sequential

way. Therefore, we use SAS to sign messages sequentially produced by the partners. Instead, whenever a parallel execution is performed, we use AS to sign and combine produced messages. As depicted in Figure 1, when an orchestration includes both parallel and sequential executions, we need to “map” SAS to AS, since the two signature schemes work on different fields. At the end of the computation, we expect the Orchestrator to perform signature verification to check its correctness. However, since AS and SAS allow every user to perform aggregate signature verification, every entity involved in the composition may verify that its computation has been correctly inserted in the workflow. To implement our scheme, it is necessary to modify the ActiveBPEL engine to support signature operations. We address the WS-Security standard to represent information in a standard way. In particular, we refer to the possibility of exchanging security data within the BinarySecurityToken field in the message header. In fact, WS-Security provides to developers the chance of defining new security tokens and store them as binary data into the BinarySecurityToken field. In particular, it is possible to force the value type of the token to respect an XML schema [8]. In order to add this security layer, we need to modify ActiveBPEL to allow intermediate operations to be performed between services’ invocations. In fact, to the best of our knowledge there is no BPEL engine supporting security features in the service composition. Therefore, we need to modify the process deployment operation by introducing a sign service to be invoked. Figure 2 shows the overall architecture of the framework. The core components are the BPEL process, the BPEL engine, and the security service [18]. BPEL engine has been modified to add security services: aggSign for the AS feature, seqAggSign for the SAS feature, and addToken for adding the security information in the SOAP header.

References [1] Organization for the Advancement of the Structured Information Standards (OASIS). http://www.oasis-open.org/home/index.php. [2] ActiveEndPoints ActiveBPEL Open Source Engine, BPEL Standard. http://www.activebpel.org/, Last visit, April 2007. [3] Bexee: BPEL EXecution Engine. http://bexee.sourceforge.net/, Last visit, April 2007.

[4] Eclipse SDK. http://www.eclipse.org, Last visit, April 2007. [5] iGrafx BPEL. http://www.igrafx.com/products/bpel/, Last visit, April 2007. [6] Oracle BPEL Process Manager. http://www.oracle.com/technology/bpel/index.html, Last visit, April 2007. [7] Parasoft BPEL Maestro. http://www.parasoft.com/BPELMaestro, Last visit, April 2007. [8] W3C XML Schema. http://www.w3.org/XML/Schema, Last visit, April 2007. [9] Web Service Choreography Description Language (WSCDL) 1.0. http://www.w3.org/TR/ws-cdl-10/, Last visit, April 2007. [10] Web Service Choreography Interface (WSCI) http://www.w3.org/TR/wsci/, Last visit, April 2007. [11] XLANG: XML-based extension of http://www.ebpml.org/xlang.htm, Last visit, April 2007.

1.0. WSDL.

[12] Gustavo Alonso, Fabio Casati, Harumi Kuno, and Vijay Machiraju. Web Services: Concepts, Architecture and Applications. Springer Verlag, 2004. [13] Mihir Bellare, Chanathip Namprempre, and Gregory Neven. Unrestricted Aggregate Signatures. Cryptology ePrint Archive, Report 2006/285, 2006. http://eprint.iacr.org/. [14] Mihir Bellare and Phillip Rogaway. Random oracles are practical: a paradigm for designing efficient protocols. In CCS ’93: Proceedings of the 1st ACM Conference on Computer and Communications Security, pages 62–73, New York, NY, USA, 1993. ACM Press. [15] Dan Boneh, Craig Gentry, Ben Lynn, and Hovav Shacham. Aggregate and verifiably encrypted signatures from bilinear maps. In Proceedings of Advances in Cryptology - Eurocrypt 2003, Lecture Notes in Computer Science, volume 2656, pages 416–432. Springer-Verlag, Berlin, 2003. [16] Dan Boneh, Ben Lynn, and Hovav Shacham. Short signatures from the weil pairing. In Proceedings of Advances in Cryptology - Asiacrypt 2001, Lecture Notes in Computer Science, volume 2248, pages 514–532. Springer-Verlag, Berlin, 2001.

[17] Business Process Modeling Language. http://www.bpmi.org. Last visit, April 2007. [18] Anis Charfi and Mira Mezini. Using aspects for security engineering of web service compositions. In ICWS ’05: Proceedings of the IEEE International Conference on Web Services (ICWS’05), pages 59–66, Washington, DC, USA, 2005. IEEE Computer Society. [19] Xiang Fu, Tevfik Bultan, and Jianwen Su. Analysis of interacting bpel web services. In WWW ’04: Proceedings of the 13th international conference on World Wide Web, pages 621–630, New York, NY, USA, 2004. ACM Press. [20] Dimitrios Georgakopoulos, Mark Hornick, and Amit Sheth. An overview of workflow management: from process modeling to workflow automation infrastructure. Distrib. Parallel Databases, 3(2):119–153, 1995. [21] Steve Graham, Simeon Simeonov, Toufic Boubez, Glen Daniels, Doug Davis, Yuichi Nakamura, and Ryo Neyama. Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI. 2001. [22] IBM, Microsoft, and BEA Systems. cess execution language for web services. http://www.ibm.com/developerworks/library/ws-bpel.

Business proAugust 2002.

[23] R. Khalaf, A. Keller, and F. Leymann. Business processes for Web Services: principles and applications. IBM Syst. J., 45(2):425–446, 2006. [24] Niels Lohmann, Peter Massuthe, Christian Stahl, and Daniela Weinberg. Analyzing Interacting BPEL Processes. In Business Process Management, 4th International Conference, BPM 2006, Vienna, Austria, September 5-7, 2006, Proceedings, volume 4102 of Lecture Notes in Computer Science, pages 17–32. Springer-Verlag, September 2006. [25] Anna Lysyanskaya, Silvio Micali, Leonid Reyzin, and Hovav Shacham. Sequential aggregate signatures from trapdoor permutations. In Proceedings of Advances in Cryptology - Eurocrypt 2004, Lecture Notes in Computer Science, volume 3027, pages 74–90. Springer-Verlag, Berlin, 2004. [26] Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, and Ronald Monzillo. Web Services Security: SOAP Message Security 1.1, OASIS. 2006. http://www.oasis-open.org/committees/download.php/16790/wssv1.1-spec-os-SOAPMessageSecurity.pdf .

[27] Mike P. Papazoglou. Agent-oriented technology in support of e-business. Communications of ACM, 44(4):71–77, 2001. [28] Petia Wohed, Wil M. P. van der Aalst, Marlon Dumas, and Arthur H. M. ter Hofstede. Analysis of Web Services Composition Languages: The Case of BPEL4WS. In Proceedings of the 22nd International Conference on Conceptual Modeling (ER), pages 200–215, 2003.