Verifying BPEL Workflows Under Authorisation ... - Semantic Scholar

Download PDF
2 downloads 0 Views 307KB Size Report
Comment
Verifying BPEL Workflows Under Authorisation ... cess Control (RBAC) into BPEL and allows us to express authorisation .... only hold under certain conditions.
Verifying BPEL Workflows Under Authorisation Constraints Zhao Xiangpeng1,2 , Antonio Cerone2 , and Padmanabhan Krishnan3 1

LMAM and Department of Informatics, School of Mathematics Peking University, Beijing 100871, China 2 UNU-IIST, Macau SAR, China 3 Centre for Software Assurance, Bond University, Australia [email protected], [email protected], [email protected]

Abstract. Business Process Execution Language (BPEL), or Web Services BPEL (WS-BPEL), is the standard for specifying workflow process definition using web services. Research on formal modelling and verification of BPEL has largely concentrated on control flow and data flow, while security related properties have received little attention. In this work, we present a formal framework that integrates Role Based Access Control (RBAC) into BPEL and allows us to express authorisation constraints using temporal logic. Using this framework, we show how model-checking can be applied to verify that a given BPEL process satisfies the security constraints. Keywords: Workflow, BPEL, RBAC, model-checking.

1

Introduction

The use of workflows based on web services is a current trend in industry. In this context a workflow can be viewed as a composition of web services which is therefore distributed, decentralized and dynamic. BPEL (Business Process Execution Language) [2] has become the standard for specifying and executing workflow specifications for web service composition. It has been developed to model business processes by describing workflows and interfaces, as well as specifying the technical infrastructure for carrying out business transactions. However, BPEL lacks security and so-called “human workflow” support. As workflow process modelling is a complicated and error-prone procedure, it is important to ensure that there are no errors when a process definition becomes operational. Thus, effective process verification in the early modelling phase is essential. Fu et al. [4] suggest a way to verify BPEL taking into account both control and data flow. Hinz et al. [5] describe how to transform BPEL into Petri Nets. However, in their work several details of BPEL, including security, are not considered. We believe that a new model combining both the web service related features and security issues is needed. Our goal is the description, outside the business process, of authorisation constraints that a workflow must satisfy and their automatic verification. S. Dustdar, J.L. Fiadeiro, and A. Sheth (Eds.): BPM 2006, LNCS 4102, pp. 439–444, 2006. c Springer-Verlag Berlin Heidelberg 2006 

440

Z. Xiangpeng, A. Cerone, and P. Krishnan

There are also works that describe injecting authorisation models into workflows [9,1], but without any attempts to give formal verification frameworks. Ribeiro and Guedes [6] use a logic-based method to verify workflows against security policies. Tan, Crampton and Gunter [8] study the consistency of various kinds of authorisation constraints and give an algorithm to determine whether the workflow can be completed under given constraints. However, the authors assume that the workflow has a very simple structure, i.e. a partial order. We believe that verification based on such a simple model is not suitable for realworld workflows. In fact, we want to integrate an authorisation model into BPEL with the ability to verify that a given BPEL business process can actually be completed under the restrictions imposed by the model. In this paper we introduce security restrictions specified using role based access control to a workflow and show how to verify whether the workflow can still be completed under the security constraints.

2

BPEL and RBAC

BPEL is an XML-based language for the composition of executable business processes based on web services. Since in the business process terminology web services are usually called tasks, we will always use the term “task” in the following. The behaviour of a business process consists of BPEL activities. We distinguish between basic activities and structural activities. There are four basic activities: assign, to assign value to variables; receive and reply, to describe data communication with the environment of the business process; invoke to describe calls to tasks offered by the environment. The last three activities are called invocation activities; they all relate to calling of tasks. As an example we will describe the process used by a library to acquire a book (Figure 1). The key activities are as follows. Any individual who is a “fellow” of the library can apply for ordering a book. An ordering request consists of the applicant’s id, the book name and the book price, described by the bookData variable. This request is modelled as a receive activity with the name orderEntry. The book will be eventually ordered only after the request passes three checks performed by a secretary, an accountant and a manager called inventoryCheck, creditCheck and evaluation, respectively. The manager has a choice (indicated by the switch construct) of either purchasing the book (called purchaseBook) or sending a reject letter to the fellow (called sendRejectLetter). In invocation activities the name of the web service is described as a tuple (partnerLink, portType, operation). For example, the inventoryCheck activity is a synchronous invocation to the operation check, which belongs to the secretary partner. It first sends bookData as input to check, and then waits for the returned result, which will be assigned to variable inventoryCheckResult. Role Based Access Control (RBAC) provides a flexible approach to model access control policies. Permissions are assigned to roles, and roles are assigned to subjects. RBAC is considered as a natural choice in business processes, where

Verifying BPEL Workflows Under Authorisation Constraints

441

... Fig. 1. BPEL Source Code for the Library Example

the permissions of performing tasks are usually assigned to roles [8]. Role hierarchy defines inheritance relations between roles, which are usually partial orders. A senior-role is a role that inherits permissions from one or more junior roles. We model a BPEL specification using a process algebra. The various activities are thus modelled as communication over channels [10]. From the BPEL perspective, partner links can be viewed as roles, and operations as permissions in RBAC. In our framework the assignment of roles to individuals is done explicitly. An agent, which can be any entity performing a certain operation, synchronises with the BPEL process (say by examining the role associated with the partnerLink) and executes the particular task. That is, the agent assumes a particular role to complete a task. As an agent can have an iterative behaviour, it can assume various roles within a particular behaviour. Informally, the semantics of an agent only specifies what the agent is willing to do — not what the agent is allowed to do. To ensure that the behaviour of an agent is suitably restricted, we also need to model a controller which checks the basic RBAC constraints. The entire system is viewed as the composition of the agents (along with the individual and role assignments) and the controller [10].

3

Authorisation Constraints and Verification

We now describe the specification of authorisation constraints based on RBAC models. The execution of a task can be associated with a particular individual

442

Z. Xiangpeng, A. Cerone, and P. Krishnan

assuming specific roles. Formally we define the sets Inds (for individuals), Roles (for roles), T asks (for tasks). The set of all possible states of computation is captured by the set of triples, Inds × Roles × T asks. We let the triple (i, r, t) be a typical state and call it an allocation for task t. We also support the use of a role hierarchy, which means that if a given role is authorised to play a task, then the roles dominating this role will inherit its execution authorisation. The role hierarchy is a partial order on Roles. In general, we can support a variety of structures on Roles (e.g., as proposed in W-RBAC [9]). The focus here is not on properties of the structures associated with such sets; rather it is on how to verify an assignment of individuals to tasks via their roles in a workflow. Using this model we can specify some high-level constraints such as separation of duties. The trace is defined as a possible “run” of the business process, based on the process definition and the allocation of agents. It captures a specific execution order of the tasks by particular individuals assuming specific roles. A constraint is viewed as a predicate on the “trace”. Thus we can use Linear Time Temporal Logic (LTL) to specify the desired properties. We use the standard modalities of LTL (♦ for eventually,  for henceforth and  for next). We introduce two basic predicates: canAssume : Inds × Roles → Bool and canPerform : Roles × T asks → Bool. These predicates are motivated by our semantics which represents the possible options declared by the agents and the options actually permitted by the controller. We note that these constraints are static and they do not depend on the execution order of the tasks. The execution order cannot be decided until the actual execution of the business process. In order to simplify the verification procedure, we avoid expressing these basic constraints directly as LTL formulae in the implementation. Instead, we express them as a predicate allow, which is incorporated within the controller, allow(i, r, t) = canAssume(i, r) ∧ canPerform(r, t). Every valid trace containing (i, r, t) must at least satisfy allow(i, r, t). In general, we use the variables i, r and t as place holders to denote the individual, role and task respectively. For instance, the formula ♦(i = i ) denotes that eventually the individual i performs some task. More precisely a trace that satisfies the formula must have the triple (i , r , t ) appearing in it for some r and t . In this paper we focus only on the verification of security related properties, in particular on “whether the business process can be completed under a set of authorisation constraints”. A constrained business process is completable under a constraint c if there exists a trace T r = (i1 , r1 , t1 ), · · · , (in , rn , tn ) · · ·  of the business process such that T r satisfies c. We are effectively verifying if the workflow description, along with the behaviour of the agents and the controller, actually satisfies the authorisation constraints. While the above infrastructure allows us to define a wide class of authorisation constraints, only a few specific examples are developed below. Separation of duty (SoD) is an authorisation principle used to prevent fraud and error by requiring that at least two individuals are involved in performing the business process. SoD is also useful when two agents have to co-operate to complete a task but neither agent should know all the details.

Verifying BPEL Workflows Under Authorisation Constraints

443

The basic form of SoD states that two given distinct tasks t1 and t2 must be performed by different individuals. This can be defined as   ∀i0 ∈ Inds • ¬



   ♦(t = t1 ∧ i = i0 ) ∧ ♦(t = t2 ∧ i = i0 )

That is, the same individual i0 cannot perform both t1 and t2 . We can also define other variations based on the above structure. For example, we can define that task t1 and task t2 must be performed by different roles as  ∀r0 ∈ Roles • ¬



   ♦(t = t1 ∧ r = r0 ) ∧ ♦(t = t2 ∧ r = r0 )

In this case the tasks may be performed by the same individual; but they must be allowed to assume different roles. We can also define an SoD constraint for a specific agent, e.g., A,  which cannot invoke both task t1 and t2 as ¬



   ♦(t = t1 ∧ i = iA ) ∧ ♦(t = t2 ∧ i = iA )

As we allow LTL formulae with quantifiers, we can also define constraints that only hold under certain conditions. For instance, we specify below the requirement that if task t0 is performed by the individual is , tasks t1 and t2 cannot be performed by the same individual.   

     ♦(t = t0 ∧ i = is ) ⇒ ∀i0 ∈ Inds • ¬ ♦(t = t1 ∧ i = i0 ) ∧ ♦(t = t2 ∧ i = i0 )

That is, the separation of duty only applies if is performs t0 at some time. Such forms of SoD are dynamic, in the sense that they rely on a particular execution of the business process. We now apply the above discussion to the example shown in Section 2. We have four roles: fellow, secretary, accountant, and manager. We consider a role hierarchy where the fellow is the least element of the partial order, the secretary and accountant are higher than the fellow but incomparable with each other, and the manager is the top element. We have five agents: Alice, Bob, Cathy, David and Elsa. We allow Alice to assume the role of a manager, (formally written as “canAssume(Alice,manager)”), Bob to be a secretary, Cathy to be an accountant, David to be a fellow and Elsa to be either a secretary or accountant. For our BPEL specification, we specify that only the manager can execute evaluation, (formally written as “canP erf orm(manager,evaluation)”), the secretary to execute inventoryCheck, sendRejectLetter or purchaseBook while the accountant can only execute creditCheck and the fellow can only invoke orderEntry. We introduce the following separation of duty constraints:     ∀i0 ∈ Inds • ¬ ♦(t = orderEntry ∧ i = i0 ) ∧ ♦(t = creditCheck ∧ i = i0 )     ∀i0 ∈ Inds • ¬ ♦(t = inventoryCheck ∧ i = i0 ) ∧ ♦(t = creditCheck ∧ i = i0 )

which requires orderEntry and creditCheck be performed by different individuals as well as inventoryCheck and creditCheck. The specifics of the verification and synthesis process have been performed using SAL (Symbolic Analysis Laboratory), a model-checker designed by SRI [7]. SAL supports special features such as quantifiers, user-defined data types, functions and infinite data types. We translate the BPEL specification into SAL. The translation is almost straightforward and we only outline the main steps. Channel communications are converted into state transitions with shared variables.

444

Z. Xiangpeng, A. Cerone, and P. Krishnan

Modules in SAL are distinct transition systems that can be combined together. Each business process or agent is defined as a module. This allows us to build different configurations of the system. We can choose particular configurations to construct the actual system to be verified. Two possible configurations related to our example are are conf1 : {bp, Alice, Bob, Cathy, David} and conf2 : {bp, David, Elsa}. SAL verifies that configuration conf1 is completable whereas configuration conf2 is not. This is because there is no manager in conf2 to perform the evaluation task. Another configuration conf3 : {bp, Alice, David} will also fail, since the separation of duty cannot be satisfied.

4

Conclusion and Future Work

In this paper, we have presented a verifiable framework for BPEL processes that addresses authorisation requirements. We provided a systematic method of integrating RBAC information with the BPEL processes. Based on the trace of the business process, we defined authorisation constraints in temporal logic. Finally, we presented how the business process can be automatically verified for completability under given authorisation constraints using the SAL model-checker. The model-checking procedure is based on the definition of a completable business process using RBAC mechanisms and constraints. Future work includes adding trust and delegation support to the model, analysing the working draft of BPEL 2.0 [3], and developing efficient translation mechanisms to reduce the state space for the verification process.

References 1. G. Ahn, R. Sandhu, M. Kang, and J. Park. Injecting RBAC to secure a web-based workflow system. In Proc. of RBAC ’00. ACM Press, 2000. 2. BPEL. Business process execution language for web services version 1.1. http://www-128.ibm.com/developerworks/library/ws-bpel/. 3. BPEL 2.0 Working Draft. Web services business process execution language version 2.0. http://www.oasis-open.org/apps/org/workgroup/wsbpel/. 2004. 4. X. Fu, T. Bultan, and J. Su. Analysis of interacting BPEL web services. In Proc. of WWW ’04. ACM Press, 2004. 5. S. Hinz, K. Schmidt, and C. Stahl. Transforming BPEL to Petri nets. In Proc. of BPM’05, LNCS 3649, 2005. 6. C. Ribeiro and P. Guedes. Verifying workflow processes against organization security policies. In WETICE99’. IEEE Computer Society, 1999. 7. SAL. Symbolic analysis laboratory. http://sal.csl.sri.com/. 8. K. Tan, J. Crampton, and C. Gunter. The consistency of task-based authorization constraints in workflow systems. In Proc. of CSFW’04, 2004. 9. J. Wainer, P. Barthelmess, and A. Kumar. W-RBAC – a workflow security model incorporating controlled overriding of constraints. International Journal of Cooperative Information Systems, 12(4), 2003. 10. X. Zhao, A. Cerone, and P. Krishnan. Modelling and resource allocation planning of BPEL workflows under security constraints. Technical Report 336, UNU-IIST, 2006. http://www.iist.unu.edu/.