Chapter 1. Introduction
1.1 Workflow management systems
Workflow management systems (WfMSs) are software systems that support coordination and cooperation among members of an organization who are performing complex business tasks [1,2,3,4,5]. The business tasks are modeled as workflow processes that are automated by a WfMS. The workflow model (also referred to as the workflow-process definition) is the computerized representation of the business process that defines the starting and stopping conditions of the process, the activities in the process, and control and data flows among these activities. An activity is a logic step within a workflow, which includes information about the starting and stopping conditions, the users who can participate, the tools, data, and resources needed to complete the activity, and the constraints on how the activity should be completed. A person who participates in the execution of an activity is called a participant of that activity. Activities are usually organized into a directed graph that defines the order of execution among the activities in the process, where nodes and edges in the graph represent activities and control flow, respectively. A workflow-process instance is the execution state of a workflow process, and the execution of a workflow-process is controlled by the workflow engine.
A WfMS is intrinsically a network-based application. For a WfMS with a single workflow engine, the participants in activities usually communicate with the workflow engine from different locations via a network system. This requires communication security to be maintained. Furthermore, for a distributed WfMS in which the activities of the workflow process can be executed in different workflow engines [6,7,8], the process
instance should be exchanged or transmitted among workflow engines via the network.
Thus, a secure network-based WfMS is required to implement major security features such as authentication, confidentiality, data integrity, and nonrepudiation [9,10].
Confidentiality involves prohibiting unauthorized disclosure of information such as the process instances or external data of a WfMS during its execution. Therefore, a WfMS usually has an access control mechanism that the system designer can use to specify how to restrict access to authorized users.
Centralized WfMSs focus on executing workflow processes within a single organization at one location in a single workflow engine (see Figure 1A). A workflow process is executed by a single workflow engine that communicates with all of the activity participants. To fit with the rapidly changing business environment and with the highly variable load of e-business applications, WfMSs should be scalable and should provide the required flexibility to cope with peaks in the system load and distributed environment. Consider the working model of the engine-based distributed WfMS shown in Figure 1B [6,7,8,11]. The workflow process has six activities (labeled as A1–A6) that are designed to be executed in three workflow engines deployed at three locations.
Establishing multiple workflow engines provides two main advantages: (1) the ability to balance the load among the workflow engines as the number of users increases, and (2) the reduced communication time between the participants in the activity and the workflow engines since the workflow engines are close to the users in terms of network transmissions. Note that administrators are required to manage the workflow engines in this model, since the workflow process instances are usually stored in them or in
database servers close to them. The user communicates with the administered workflow engines to participate in the execution of the WfMS via the network.
A1
Figure 1. Working models of a centralized WfMS (A) and an ordinary engine-based distributed WfMS (B).
In these applications it is essential for a WfMS to store the state of a workflow process (i.e., the process instance). Also, it is obvious that the workflow process instances must be transmitted during the execution of the workflow process because the distances between these workflow engines are too great for them to share the workflow process instances. As an example, in Figure 1B workflow engine 1 must send the
workflow process instance that contains the execution result of activity A1 to workflow engines 2 and 3. It is also possible that workflow engines in a distributed WfMS are executed in heterogeneous machines. Thus, it is obvious that the interchange of workflow process instances between different types of workflow engine must be supported in this type of environment.
For the working model shown in Figure 1B, the workflow process instances might be transmitted on a public network such as the Internet. This introduces possible security problems including (1) the workflow process instances containing the execution results of activities, which could be eavesdropped, and (2) malicious users intercepting the process instances and then altering their contents before passing them on to the next workflow engine. Although these two problems can be easily solved by applying common methods used to secure electronic transactions with secure sockets, such as the SSL (Secure Sockets Layer) protocol [9], they cannot guarantee the nonrepudiation requirement; that is, it is difficult for the system to prevent a participant from denying what he/she had done in an activity. Activity participants connect to some workflow engine in order to execute the activity in this working model. The communication between participants and workflow engines is very similar to a client/server computing model and workflow engines always have a fixed domain name, which makes it easy for a participant to discover them. Due to security requirements such as confidentiality, the workflow engine shows only certain parts of the data in the process instance (e.g., some forms, texts, pictures, and files) to the participant, and the participant then sends the execution results (e.g., some texts or files) to the connected workflow engine. The workflow engine stores obtained execution results in a database or other storage device
as part of the process instance. After an activity has been executed it is possible that the participant will repudiate his previous execution by claiming that the stored execution results have been altered or that the forms shown to him/her by the workflow engine during the execution of activity are inconsistent, incorrect, or have been modified illegally.
In addition, an engine-based WfMS (either centralized or distributed) encounters several difficulties. The first is that its architecture lacks scalability. Although we can increase the number of workflow engines to enhance the processing capability, the accesses and coherence of shared workflow process instances represent a bottleneck. If a process instance is replicated in several servers, we have to use a coherence protocol to maintain the consistency between concurrent accesses of it. Also, the load should be balanced between these workflow engines [12]. Second, the engine-based system is susceptible to a denial-of-service attack because the workflow engine always has a fixed location (or domain name). In such an attack the enemy interferes with the system by making excessive and pointless invocations on services or message transmissions in a network so as to overload the physical resources (e.g., network bandwidth and server processing capacity). The intention of most such attacks it to delay or prevent actions by other users. Third, the security of a process instance is ensured by the server but not by the process instance itself. Note that the workflow servers in inter-enterprise WfMSs may be administered by different organizations in a distributed network environment.
The security of the entire system is ineffectual if the security mechanism in any of the servers that may access or store the process instance is broken. The question then arises
about how to design a trust model for workflow engines in inter-enterprise or cross-organization WfMSs.