工作流程管理系統與呼叫鍊的安全性架構

全文

(1)國立臺灣師範大學資訊工程研究所博士學位論文. 指導教授：黃冠寰博士. 工作流程管理系統與呼叫鍊的安全性架構 The Security Framework for WfMS and Calling Chain. 研究生：蕭宇程中華民國. 一百零二. 撰年. 六. 月.

(2) The Security Framework for WfMS and Calling Chain. A dissertation presented by Yu-Cheng Hsiao. to. the Dept. of Computer Science and Information Engineering. in partial fulfillment of the requirements. for the degree of Doctor of Philosophy. in the subject of Computer Science. National Taiwan Normal University Taipei, Taiwan, R.O.C 2013.

(3) Table of Contents Table of Contents ............................................................................................................. i List of Figures iii 中文摘要. vi. Abstract. viii. 謝誌. xi. Chapter 1.. Introduction ............................................................................................. 1. 1.1. Workflow management systems ............................................................. 1. 1.2. Introduction of CWSM ........................................................................... 6. 1.3. Introduction of DRA4WfMS and cloud support .................................. 10. 1.4. Service-Oriented Architecture .............................................................. 13. 1.5. Introduction of DRA4SOA ................................................................... 18. Chapter 2.. Related Works ....................................................................................... 21. 2.1. Related works of CWSM ...................................................................... 21. 2.2. Related works of DRA4WfMS ............................................................. 25. 2.3. Related works of DRA4SOA ................................................................ 31. Chapter 3.. CWSM .................................................................................................. 36. 3.1. Related works of DRA4SOA ................................................................ 36. 3.2. General Access Control Model in WfMSs ............................................ 43. 3.3. API to Specify the Security Policy for the CWSM in WfMSs ............. 45. 3.4. Run-time System for the CWSPS API and Implementation ................. 52. 3.5. An Implementation Example of CWSM............................................... 59. Chapter 4.. DRA4WfMS ......................................................................................... 61. 4.1. Operational Model of the DRA4WfMS ................................................ 61. 4.2. Implementing information security in the DRA4WfMS ...................... 76. 4.2.1. Authentication ....................................................................................... 76. 4.2.2. Confidentiality and Data Integrity ........................................................ 77. 4.2.3. Nonreputiation ...................................................................................... 77 i.

(4) 4.3. Syntax of the DRA4WfMS Document ................................................. 80. 4.4. Applying the DRA4WFMS in the Cloud Computing Environment ..... 97. 4.5. Implementation and Experimental Results of DRA4WfMS .............. 99. Chapter 5.. DRA4SOA .......................................................................................... 108. 5.1. CCG. 1. 0. 8. 5.2. Operational model of DRA4SOA ....................................................... 111. 5.3. Security requirements achieved in the DRA4SOA ............................. 128. 5.4. Implementation of DRA4SOA messages in Web services ................. 130. 5.5. DRA4SOA API ................................................................................... 136. 5.6. Simplified DRA4SOA messages ........................................................ 139. 5.7. Implementation and experimental results of DRA4SOA ................... 141. Chapter 6.. Conclusions and future work .............................................................. 145. References. 149. Appendix A. 159. Appendix B. Writing policy objects in the DRA4SOA API ....................................... 160. ii.

(5) List of Figures Figure 1. Working models of a centralized WfMS (A) and an ordinary engine-based distributed WfMS (B). ............................................................................ 3 Figure 2. Examples of company information for the CWSM ......................................... 7 Figure 3. An example SOA application from the literature. ......................................... 16 Figure 4. An SOA application. ...................................................................................... 17 Figure 5. The first motivation example ......................................................................... 38 Figure 6. Pseudo code of RBAC ................................................................................... 39 Figure 7. The second motivation example .................................................................... 40 Figure 8. Pseudo code of RBAC ................................................................................... 41 Figure 9. General access control model of a WfMS ..................................................... 43 Figure 10. The Backus Naur Form of the CWSPS API and some examples ................ 49 Figure 11. Architecture for supporting the execution of the CWSPS API in a WfMS . 53 Figure 12. Example history tables ................................................................................ 55 Figure 13. Algorithms for the CWSM .......................................................................... 57 Figure 14. Algorithms for performing passive and active data access in the CWSPS API ........................................................................................................ 58 Figure 15. An example of a Java program that invokes the CWSPS API .................... 60 Figure 16. Example of element-wise encryption .......................................................... 62 Figure 17. Basic operational model of the DRA4WfMS .............................................. 63 Figure 18. The control flow of some workflow processes ............................................ 68 Figure 19. Example illustrating the problem of data concealment ............................... 71 Figure 20. Advanced operational model of the DRA4WfMS....................................... 72 Figure 21. Document routing through the TFC server.................................................. 74 Figure 22. Architecture of a DRA4WfMS document ................................................... 79 Figure 23. XML-based syntax of a DRA4WfMS document ........................................ 82 iii.

(6) Figure 24. Syntax of the workflow definition ............................................................... 84 Figure 25. Example of the structure of organization units ............................................ 85 Figure 26. Syntax of the participant element ................................................................ 86 Figure 27. Example XML document of a <Participant> element ............................... 88 Figure 28. Syntax of a <Presentation> element ......................................................... 88 Figure 29. Example of a <Presentation> element ...................................................... 89 Figure 30. Examples of key definitions ........................................................................ 90 Figure 31. Example of algorithm definition ................................................................. 90 Figure 32. Syntax of encryption definition ................................................................... 93 Figure 33. Example XML document of an <EncryptionDefinition> element ............ 94 Figure 34. Syntax of a CER .......................................................................................... 96 Figure 35. Applying the DRA4WfMS in the cloud computing environment ............... 98 Figure 36. Codes to invoke the DRA4WfMS API to construct an AEA .................... 101 Figure 37. Two workflow processes for conducting experiments .............................. 102 Figure 38. An example of a CCG................................................................................ 109 Figure 39. A calling chain with asynchronous invocation .......................................... 109 Figure 40. The DRA4SOA operational model ............................................................ 111 Figure 41. Structure of a DRA4SOA message when other services do not need to be invoked to process D(REQi) ............................................................... 113 Figure 42. Structure of a DRA4SOA message when other services do need to be invoked to process D(REQi) ............................................................... 114 Figure 43. The form of the messages in a synchronous invocation ............................ 115 Figure 44. The form of the messages in an asynchronous invocation ........................ 116 Figure 45. The message for building a CCG scenario ................................................ 121 Figure 46. An example to illustrate Algorithm 2 ........................................................ 123 Figure 47. An example to illustrate Algorithm 2 (Cont’d).......................................... 123 Figure 48. An example to illustrate Algorithm 2 (Cont’d).......................................... 124 iv.

(7) Figure 49. An example to illustrate Algorithm 2 (Cont’d).......................................... 125 Figure 50. An example to illustrate Algorithm 2 (Cont’d).......................................... 126 Figure 51. An example to illustrate Algorithm 2 (Cont’d).......................................... 127 Figure 52. A SOAP message embedded in a DRA4SOA message ............................. 131 Figure 53. Syntax of the DRA4SOA message ............................................................ 132 Figure 54. An example of a SOAP message with the DRA4SOA message ............... 134 Figure 55. An example of a <Signature> element .................................................... 135 Figure 56. The DRA4SOA API class diagram ............................................................ 136 Figure 57. Codes for invoking the DRA4SOA API .................................................... 137 Figure 58. The simplified <content> element ........................................................... 139 Figure 59. Class diagram of the CWSPS API implemented in Java ........................... 159 Figure 60. Some methods in the DRA4SOA API ....................................................... 160 Figure 61. Some examples of Java codes that use the DRA4SOA API ...................... 161 Figure 62. An example of Java codes to traverse a CCG in the DRA4SOA API ....... 162. v.

(8) 中文摘要安全的工作流程系統(Workflow Management System, WfMS)與服務導向架構 (Service-oriented architecture, SOA)必須要支援像是身分驗證機制、資料保密性、資料完整性以及不可否認性等安全性需求。中國牆安全模型(Chinese wall security model)主要用於提供商業組織中避免利益衝突的存取控制，在大型跨企業的工作流程中顯得特別重要。本論文的第一個部份提出如何將中國牆安全模型實作於工作流程系統中，我們先展示現有的存取控制模型由於沒有考慮到執行時期的歷史紀錄與公司組織資訊的變動性而不足以支援此安全性架構，而提出了一組應用程式介面並支援動態存取控制對象與公司資料的繫結。此應用程式介面也可用於定義動態的安全性政策來達成將中國牆安全模型實作於工作流程系統的安全性需求，並討論如何將這些特性實作於執行時期的工作流程系統。雲端運算(Cloud computing)技術目前不論是在學術或是業界都引起了很大的注意，越來越多使用者與企業都將資料與應用程式搬移到雲端上。雲端運算提供可擴充性、支援大型資料數據、依據需求來調整的資源分配技術，這些特性對於如何將工作流程系統實作於雲端上是相當有挑戰性的。要建立一個可擴充性高的跨企業工作流程系統需要將現有流程管理的概念加以運用及擴展，本論文的第二個部份提出一個工作流程的安全性架構如何被安全有彈性地實作於跨企業的工作流程中，並提出現有以工作流程引擎為基礎的工作流程系統難以達成不可否認性的安全性需求。我們提出的系統架構為一個文件傳遞式並支援主要安全性需求的雲端環境系統，它運用了元素式加密法和鏈狀數位簽章等技術讓工作流程程序實例擁有自我保護的能力，並可以滿足身分驗證機制、資料保密性、資料完整 vi.

(9) 性以及不可否認性等安全性需求。而且工作流程程序實例可以備份及遷移至其他相容的平台而不必依靠雲端服務提供者的支援。在本研究中，我們實作了整個系統的雛型並進行相關的實驗與研究，並提供了充分的實驗結果。在服務導向架構的系統中，應用程式通常會以網路服務(Web service)來進行實作，而網路服務的呼叫常會產生動態的呼叫鍊(Calling chain)。現有的服務導向架構安全性機制像是 WS-Security、WS-SecurityPolicy 及 WS-Trust 都只支援點對點式的安全性。在本論文中的第三個部份中，我們首先說明了需要呼叫鍊動態資訊的存取控制情境，並提出一個滿足主要安全性需求的以服務導向架構為基礎的安全性架構，此架構會在每個服務呼叫時產生呼叫記錄(Calling record) 並且將此資訊加入到呼叫中，藉此建立可以用來支援基於呼叫鍊存取控制的呼叫鍊圖型(Calling-chain graph)，我們也設計了一組安全性政策應用程式介面來讓服務提供者制定基於呼叫鍊的存取控制，並提供了實作與實驗結果以展示本研究所提出之系統的可行性。. 關鍵字：工作流程系統、中國牆安全性模型、安全性、雲端運算、服務導向架構、呼叫鍊. vii.

(10) Abstract Secure workflow management systems (WfMSs) and SOA (service-oriented architecture) system are required to support major security features such as authentication, confidentiality, data integrity, and nonrepudiation. The Chinese wall security model (CWSM) was designed to provide access controls that mitigate conflict of interest in commercial organizations, and is especially important for large-scale interenterprise workflow applications. The first part of this dissertation describes how to implement the CWSM in a WfMS. We first demonstrate situations in which an access control model is not sufficient for this if the WfMS does not keep the run-time history of data accesses and company information is mutable, and we then propose an application programming interface (API) to solve this problem, also providing support for the intrinsic dynamic access control mechanism defined in the CWSM (i.e., the dynamic binding of subjects and elements in the company data set). This API can also specify several requirements of the dynamic security policy that arise when applying the CWSM in WfMSs. Then we discuss how to implement a run-time system to implement CWSM policies specified by this API in a WfMS. Cloud computing is gaining tremendous momentum in both academia and industry, with more and more people and enterprises migrating their data and applications into the cloud. Cloud computing provides a new computing model with elastic scaling, a resource pool of unprecedented size, and the on-demand resource provisioning mechanism, which bring numerous challenges in implementing workflow management systems (WfMSs) in the cloud. Establishing scalable and cross-enterprise WfMSs in the cloud requires the adaptation and extension of existing concepts for process management. The second part of this dissertation presents a framework for viii.

(11) how cross-enterprise processes can be implemented, secured, controlled, and scaled. We also explain why existing engine-based centralized and distributed WfMSs cannot guarantee the nonrepudiation. requirement.. The proposed framework is. a. document-routing system that implements major required security features in the cloud computing environment. Its security framework is built by applying element-wise encryption and a cascade-based method of embedding digital signatures. The implementation and experimental results demonstrate the feasibility of the proposed framework. In an SOA (service-oriented architecture) system such as an application implemented by Web services, the invocations of services often form dynamic calling chains. Existing security standards of an SOA such as WS-Security, WS-SecurityPolicy, and WS-Trust only support the point-to-point security requirements of individual Web services. In the third part of this dissertation. We first show some scenarios in which the access control and data security must consult the structure of a dynamically formed calling chain in a wide-open distributed environment. We then propose a security framework for SOA-based systems in which the access control and data security can be performed dynamically according to the formed calling chain in service invocations. The proposed framework satisfies security requirements in a service invocation. A calling record is embedded in each service invocation and response, and these calling records are used when building a calling-chain graph that can be used to implement the calling-chain-based access control. In addition, we design a security policy API that the service provider can use to specify the access control and data security according to the formed calling chain. The implementation and experimental results demonstrate the feasibility of the proposed system. ix.

(12) Keywords: Workflow management system (WfMS), Chinese wall security model (CWSM), Security, Cloud, SOA, Calling chain. x.

(13) 謝誌首先必須感謝我的指導教授─. 黃冠寰教授，這麼多年來的指導，讓我不論. 是在學問上或是待人處事上都學到了很多。感謝這次論文的口試指導教授們：王豐堅教授、林志敏教授、黃國展教授、朱慧德教授，給予我專業的建議與未來的改進方向。感謝實驗室的夥伴們：張道顧學長、林哲生學長、游智皓學長、張昇賀學長、陳揆驩同學、張宇軒同學、吳李祺學弟以及其他學弟妹們曾經給我的幫助與鼓勵。資訊領域是我從小的嚮往，五歲時家裡的台製 Apple2、國小時 32 位元的 386 個人電腦、高中時的 56K 撥接數據機、大學時學了 Java 程式語言、到這幾年的智慧型手機，這些都是改變世界的技術，是我成長過程中無可磨滅的記憶，也是我保持對資訊領域熱情的原因。在這個瞬息萬變的年代，或許我這幾年來的研究放到十年二十年後早已乏人問津，但我知道我這些年來學習到的並不只有知識的成長，而是一種求學問的方法、看待任何事物的態度、自我探索的過程。如今唸完學歷的頂點成為博士，就我自己所相信會是我人生的另一個開始，願我不會辜負自己的才學，成為一個真正有用的人。最後感謝我的家人，爸爸、媽媽、姊姊，在唸書求學問的過程中是這麼樣地全力支持我，希望我不會讓你們失望，我永遠愛你們。. 蕭宇程. 謹誌於. 國立臺灣師範大學. 資訊工程研究所. 中華民國一零二年六月 xi.

(14) 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 1.

(15) 2. 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.

(16) 3. database servers close to them. The user communicates with the administered workflow engines to participate in the execution of the WfMS via the network.. A2. (A). A3. A1. A4. A5. A6. Workflow engine. Workflow engine 2 A2. A3 Public network. Public network. (B). A1 Workflow engine 1. Public network. A4. A5. A6. Workflow engine 3 Start of workflow. End of workflow. Activity. Flow control edge. Workflow engine User communication. Process instance migration Participant. 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.

(17) 4. 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.

(18) 5. 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.

(19) 6. about how to design a trust model for workflow engines in inter-enterprise or cross-organization WfMSs.. 1.2 Introduction of CWSM The first part of this dissertation presents how to implement the CWSM in a WfMS. The CWSM, which is also called the Brewer and Nash model [13], and is constructed to provide information security or access controls that can change dynamically. This model was designed to provide controls that avoid conflict of interest (COI) in commercial organizations. Data are viewed in this model as consisting of objects that belong to particular companies. Access to particular parts of data is not constrained by their attributes but rather by what data the subject already holds access rights to. Note that the access related to read, write, or read-and-write operation. The company data set is categorized into mutually disjoint COI classes, as shown in Figure 2. For example, banks, oil companies, and airline companies belong to different COI classes, and the CWSM policy prohibits information flows from one company to another that cause COI. Thus, if a subject accesses the information of bank B1, then s/he is not allowed to access information of other companies within the same COI class, such as that of bank B2 or Bi. However, the subject can access information in another COI class, such as objects of oil company O1..

(20) 7. Company Information. Bank. Oil Company. Airline Company. Conflict of interest class. Company data set. Individual objects. B1. 1. B2. 2. … 1. Bi. O1. O2. …. Oj. A1. A2. …. …. Other conflict of interest class. Ak. 2. Figure 2. Examples of company information for the CWSM. The CWSM proposes the following mandatory read and write rules:.  BN read rule: Subject S can read object O only if O is from the same company information as some object read by S, or O belongs to a COI class within which S has not read any object.  BN write rule: Subject S can write object O only if S can read O by the BN read rule, and no object can be read that is within a different company data set from the one for which write access is requested.. Many access control mechanisms have been proposed and implemented. Access control is traditionally implemented using an access control matrix (ACM), in which an access request from a subject can be granted if the requested access right is recorded in the matrix [14]. The role-based access control (RBAC) model is regarded as a neutral policy and has been the most popular security model in recent years [15]. Data access is.

(21) 8. restricted to authorized users in this approach, and it represents a newer alternative approach to mandatory access control and discretionary access control [14]. Roles are created for various operations within an organization, with the permissions to perform certain operations being assigned to specific roles. Subjects are assigned particular roles, through which they acquire the permissions to perform particular operations. RBAC has been applied to access control in WfMSs [16,17,18,19]. Although RBAC has been successful in various applications, we have found it to be difficult for conducting higher level access control such as the CWSM in WfMSs. When the company information used in a workflow process is static, then RBAC can implement the BN read rule. However, RBAC has problems in implementing the BN read rule if the company information is dynamic. There are at least two cases to consider. The first case is where the same workflow definition uses different company information. Although we know the structure of the company information, we need to design different codes to apply RBAC to them. The second case is where the company information may be created or updated dynamically during the execution of the workflow process. In this case the code for implementing RBAC need to bind subject to objects dynamically. A lack of knowledge of the COI class and company data set prior to executing the workflow process makes it impossible to design the code for operating RBAC in advance. In the second situation we need to apply the BN write rule during the execution of the workflow process. Because the application of the BN write rule requires the use of the object access history and the company information to decide if permission for a write operation should be granted, it is impossible to implement the BN write rule purely in RBAC without storing the object access history and the company information in the workflow engine. The.

(22) 9. main factor making RBAC difficult to implement CWSM is access permission in RBAC being controlled by the binding relationships among subjects, roles, and objects. However, access control in the CWSM depends on the object access history and company information to determine if an access request should be granted. Section 3.1 provides several examples to illustrate these two situations. In this dissertation we show how to implement the CWSM in a WfMS. It is obvious that we should solve the problems that cannot be solved by the popular RBAC model. Our solution is to design an API that allows the system developer to specify the CWSM policy in a WfMS. The proposed API is designed to satisfy the following dynamic security requirements for the CWSM:. 1. Dynamic binding between subjects and companies: The binding of a subject and a company can be dynamically implemented during the workflow execution. For example, according to the company information shown in Figure 2, if a subject requests access to objects of bank B1 and this access is successful, then s/he is bound to B1. This is the basic requirement that makes the information security access controls of the CWSM able to change dynamically. 2. Dynamic company information manipulation: The company information should be able to be created, chosen, or updated dynamically during the workflow execution. As a result, the same workflow definition can use different company information. 3. Privileged subject management: The binding of subjects to company information can be controlled during the execution of the workflow process. In some applications, not all data accesses of the participants in a WfMS should be controlled by the CWSM..

(23) 10. 4. Temporal-based enforcement: The time or duration when the CWSM policy is applied should not be static. In some situations, we may want to set up the CWSM policy to be applied only on part of the activities in a workflow process.. In general, implementing the CWSM should depend on the dynamic behavior of the workflow process. That is, it should be possible to synchronize operations related to the CWSM policy with the progression of the workflow process. This enhances the flexibility of the CWSM because our framework synchronizes access control with the execution of WfMSs. By using the proposed API, the workflow engine creates data access history tables that store dynamic data accesses performed by subjects. Instead of specifying each data access according to the company information, the workflow engine consults the data access history tables and company information to control the data access so as to implement the CWSM security requirement.. 1.3 Introduction of DRA4WfMS and cloud support The second part of this dissertation we present the design and implementation of a proposed WfMS architecture for solving these problems in engine-based distributed WfMSs, which we have called the Document-Routing Architecture for a WfMS (DRA4WfMS). It is not only a distributed WfMS but also a totally engine-less WfMS. The activity execution is not controlled by a workflow engine but is carried out by a software agent in the local computer of the activity participant. The software agent can be located anywhere or be any type of computer device without limitation. We employ the element-wise encryption for XML security [20,21] and propose a cascade-based.

(24) 11. method to embed digital signatures in the routed documents. The result is that a DRA4WfMS document is able to be secured without using an access-control server. A DRA4WfMS document contains the secured workflow definition, process instance, and some digital signatures. During the execution of an activity, the software agent parses the received DRA4WfMS document to verify the previously embedded digital signatures, decrypt and show information in the process instance to the participant, append the input of the participant to the received DRA4WfMS document, embed a new digital signature of the participant, and send out the modified DRA4WfMS document to the subsequent participant(s) according to the protocol defined for DRA4WfMS documents. The DRA4WfMS has the following features:.  It can work without a centralized workflow engine that would have to be maintained by the administrator of the WfMS.  The workflow process instance can be stored in a format that implements required security features such as authentication, confidentiality, data integrity, and nonrepudiation.  The DRA4WfMS can support dynamic flow control and a dynamic security policy in its run-time environment.  Although the execution of activity is not controlled by a workflow engine, workflow monitoring is supported.. Some of the many languages that have been proposed for supporting the interchange of the workflow process definition between different workflow products such as.

(25) 12. modeling tools and workflow engines are WfMC’s XPDL (XML-based Process Definition Language) [22], BPMI’s BPML (Business Process Modeling Language) [23], OASIS’s BPSS (Business Process Specification Schema) [24], BPEL (Business Process Execution Language) [25], and WSCI (Web Service Choreography Interface) [26]. However, it is important to realize that these languages only represent standards for the workflow process definition, and do not provide the ability to define the workflow process instance in the workflow execution. The technology proposed herein can also be applied to a centralized or engine-based distributed WfMS because it provides an appropriate method for storing the workflow process instance that is consistent with these security requirements. Cloud computing provides computation, software, data access, and storage services that do not require end-user knowledge of the physical location and configuration of the system that delivers the services. Some companies and organizations are becoming increasingly concerned about the costs of creating and maintaining applications in traditional ways, and are considering running their applications in a cloud computing environment maintained by cloud providers. The cloud computing environment can scale to any throughput requirement, although the cost will increase with its size. The associated WfMSs need be durable and resilient to any failures. A popular way to construct WfMSs in the cloud is to deploy workflow engines in the cloud computing infrastructure; examples of this approach include RunMyProcess [27], Visual Workflow [28], Aneka [29], Azure Services Platform [30], and Google App Engine [31]..

(26) 13. 1.4 Service-Oriented Architecture Service-oriented architecture (SOA) is a paradigm for organizing and using distributed services that may be under the control of different ownership domains [32]. An SOA provides a uniform means of offering, discovering, and interacting with and using services to produce desired effects consistent with measurable preconditions and expectations. Being service oriented requires services to be only loosely coupled to operating systems and other technologies that underlie applications. An SOA separates functions into distinct units, or services [33], which developers make accessible over a network so that users can combine and reuse them when developing applications. These services communicate with each other by exchanging data or by coordinating an activity between multiple services. An SOA can be implemented by a software system such as Web services [34], which make functional building blocks accessible over standard Internet protocols independently of platforms and programming languages. These services can be new applications or wrapped around existing legacy systems to make them network-enabled. The most common security scheme available for today’s Web services is SSL (Secure Sockets Layer) [35], which is typically used with HTTP. Despite its popularity, SSL has some limitations related to Web services. Achieving Web services security requirements of authentication, confidentiality, data integrity, and nonrepudiation requires numerous security standards, such as WS-Security, WS-SecurityPolicy, and WS-Trust. The WS-Security standard was designed to use the XML Encryption and XML Signature specifications for message-level confidentiality and integrity. By signing and encrypting at the message level, senders can control whether.

(27) 14. intermediaries are allowed to modify or view the content in transit. Additionally, the entire message can be stored intact, which maintains integrity and confidentiality. Because message integrity is provided by digital signatures, nonrepudiation can be achieved by logging individual messages for later retrieval [36]. WS-SecurityPolicy defines a set of security policy assertions used in the context of the WS-Policy framework that describe how messages are secured on a communication path [37]. WS-Trust defines extensions that build on WS-Security to provide a framework for requesting and issuing security tokens, and to broker trust relationships [38]. However, in general these existing Web-service security models only consider the access control and data security of individual services, and can only be applied to fulfill the security requirements of a point-to-point service invocation. These works have helped to build the foundation for Web-service security, but are inadequate for applications in which the service invocations form a calling chain. Each building block in a Web-services-based system can play one or both of two roles: (1) the service provider creates a Web service and possibly publishes its interface and access information to the service registry, and (2) the service consumer (or Web-service client) locates entries in the broker registry using various discovery operations and then binds to the service provider in order to invoke1 one of its Web services. The service provider and service consumer perform the invocation and response in a point-to-point manner. The invocation of a Web service can be either synchronous or asynchronous. In a synchronous invocation of a Web service, the client connection remains open from the. 1. In this dissertation we use the two terms “call” and “invoke” interchangeably..

(28) 15. time the invocation is submitted to the service provider. The client will wait until the service provider sends back the response message. The advantage of using synchronous communication is that the client application is rapidly informed of the status of the Web-service operation (either it receives a response or it times out). An asynchronous invocation is made to a service while the client continues execution, until either the specified callback is made or, if the callback is not provided, until blocking or polling occur or waiting for the call to complete. The Web service can handle an asynchronous call competently without requiring any additional functionality. The client decides whether to call synchronously or asynchronously. Many methods are available for performing asynchronous calls, with the most common being to use a call-back handler. A calling chain occurs in ordinary programming language when a called subroutine calls another subroutine before it is finished [39]; this is also referred to as nested subroutine calls, and can exist in distributed computation models such as RPC [40], RMI [41], and Web services. This dissertation employs Web services to demonstrate the proposed security framework that we believe can be applied to any SOA framework. Karp presented an example of why information about calling chains is required for access control in an SOA environment [42]. Figure 3 shows an SOA application with three domains that are provided by different service providers. Domain 1 provides weather prediction services, services in Domain 2 access satellite images, and services in Domain 3 return topographic data. An arrow represents a service invocation, such as Alice first calling A6 for starting this calling chain, and then A6 calls B5, B5 calls both A3 and B2, etc. In this scenario Alice is considered to.

(29) 16. be the originator of the invocation. If Alice has the authority to use service D5, when she is the originator she can use the service. However, if the originator is Bob who does not have the authority, he cannot use the service. Although we can employ security standards such as WS-Security, WS-SecurityPolicy, and WS-Trust to support the point-to-point security requirements, there is no way to capture the ID of the originator due to the lack of calling-chain information—this access control requirement will not be accomplished. In this scenario it seems that authentication of the originator of a calling chain is required for the access control. Below we present a more complicated example in which nonrepudiation is required when a calling chain forms.. Alice. A1. B1. C1. D1. A2. B2. C2. D2. A3. B3. C3. D3. A4. B4. C4. D4. A5. B5. C5. D5. A6. B6. C6. D6. A7. B7. C7. D7. Domain 1. Domain 2. Domain 3. Figure 3. An example SOA application from the literature..

(30) 17. Payment service. Digital-photo printing service Alice (Originator). Photo retouching service Printing service. Shipping service. Figure 4. An SOA application.. Figure 4 shows an SOA application that provides a digital-photo printing service. When this service receives an order, it will invoke the “payment service” with the credit card information in the order. Then, according to the requirements of this order, it will send the photos that need retouching to the “photo retouching service.” Finally the “digital-photo printing service” sends the photos after retouching and also the photos that do not require retouching to the “printing service” for printing and ships them with the partnered “shipping service.” In this scenario, the order message that Alice (the originator) sends to the “digital-photo printing service” has to contain all of the information needed by this service, including the relevant photo images, the sizes and how many copies are needed for each of them, which photos require retouching for improving their image quality, the credit card information for the payment, and the address and contact information of the receiver for shipping. The services involved in.

(31) 18. this scenario need to specify the policies according to certain information in a dynamically formed calling chain. First, the “payment service” needs to ensure nonrepudiation for the service invocation of the originator, and that the credit card information can only be read by the payment service. Second, the “photo retouching service” needs to confirm that the originator has been registered. Third, the “photo retouching service,” “printing service,” and “shipping service” must ensure that the “payment service” has been successfully invoked. It is obvious that existing standards such as WS-Security, WS-SecurityPolicy, and WS-Trust are insufficient for implementing the security requirements described in this scenario because the definable security policies cannot refer to the context of the formed calling chain. In this situation, the system developer may have to employ an entity such as a trusted third party to facilitate interactions between service providers and a third-party repository service, which appears to make it necessary to record service invocations.. 1.5 Introduction of DRA4SOA In this dissertation we propose a security framework, called DRA4SOA (document routing architecture for SOA), for implementing calling-chain security2 in an SOA environment. The solution is to embed the calling record in each invocation and response message of a service invocation, and chain these calling records with digital signatures. A calling chain formed from a sequence of service invocations can be used to build a calling-chain graph (CCG) according to embedded calling records. A service provider constructs a CCG when it receives a service invocation or response,. 2. Calling-chain security is also referred to as service-chain security [91,92,93]..

(32) 19. and then uses it to perform access control. Since calling records are chained by cryptographic algorithms, the proposed framework can fulfill security requirements of authentication, confidentiality, data integrity, and nonrepudiation without requiring a third-party repository service or requesting security tokens from a trusted third party. Moreover, we design a security policy API (Application Programming Interface) based on the CCG that service providers can use to specify the invocation control statements for performing access control based on the information in a CCG. In addition, the proposed framework is compatible with existing Web-service security standards such as WS-Security, WS-SecurityPolicy, and WS-Trust; the point-to-point Web-service security is still guaranteed by them. There are three main contributions in this dissertation which are organized as follows. Chapter 2 discusses the related work. The CWSM is my first contribution, as described in Chapter 3. Section 3.1 uses several examples to demonstrate the limitation of applying RBAC to implement the CWSM in a WfMS. Section 3.2 describes general access control models for WfMSs. Section 3.3 presents the proposed API that is used to specify the CWSM policy in a WfMS. Section 3.4 discusses how to implement the CWSM policy in a WfMS in the proposed API, and the implementation details are presented in Section 3.5. The DRA4WfMS is my second contribution, as described in Chapter 4. In Section 4.1 we present the basic and advanced operational models of the DRA4WfMS. The security mechanism of the DRA4WfMS is analyzed in Section 4.2. Section 4.3 presents the syntax of the DRA4WfMS document. We propose the DRA4WfMS API (which is an application programming interface to support the operational model) and show the implementation details and experimental results in.

(33) 20. Section 4.4 and Section 4.5. The DRA4SOA is my third contribution, as described in Chapter 5. Section 5.1 presents the definition of a CCG. Section 5.2 introduces the operational model of DRA4SOA. Section 5.3 discusses what kind of security requirements can be achieved in the DRA4SOA. Section 5.4 shows the syntax of a DRA4SOA message. Section 5.5 describes the DRA4SOA policy API, which is based on the CCG. Section 5.6 presents a simplified version of a DRA4SOA message, which can improve the processing efficiency in the DRA4SOA. The implementation details and experimental results are given in Section 5.7. Finally, conclusions are drawn in Chapter 6..

(34) Chapter 2. Related Works 2.1 Related works of CWSM Many access control techniques have been proposed. Traditional access control models such as the static access control of the ACM is insufficient in WfMSs [14]. Olivier et al. proposed an approach for dynamically granting access rights to subjects during the execution of a workflow [43]. Knorr reported dynamic access control matrices for WfMSs that used the Petri net to model WfMSs, with access rights changing with the marking of the Petri net [44]. Thomas and Sandhu proposed modeling access controls from a task-oriented rather than a subject-object perspective [45]. Their approach constantly monitors access permissions, which are activated and deactivated in accordance with emerging context associated with progressing tasks. The approach applies task-based access control (TBAC) to WfMSs and enables the granting and revoking of permissions to be automated and coordinated with the progression of activities in a WfMS. Dong et al. also proposed an access control model based on TBAC that took two basic dynamic factors into account: the state of the authorization processes and the state of the process instances [46]. Multilevel security (MLS) has posed a challenge to the computer security community since the 1960s [47]. In MLS, security levels are assigned to subjects and objects. Higher level users must have access permission to lower level objects, and higher level objects must not leak to lower level subjects or objects. Kang et al. worked on implementing the MLS model in a WfMS [48,49]. Wietrzyk et al. proposed an approach to security distributed workflow database management system based on MLS [50]. 21.

(35) 22. RBAC has been employed to implement access control mechanism in WfMSs. Atluri and Huang proposed a workflow authorization model that allows subjects to gain access to required objects during the execution of a specific task [51]. The authorization can be synchronized with the execution of the workflow process. Bertino et al. presented a language for defining constraints on role assignment and user assignment to tasks in a workflow to allow the separation of duties to be specified in a WfMS [16]. The many studies that have addressed workflow security issues have generally focused on access control and separation-of-duty issues. Park et al. addressed the security services for a secure workflow system to support dynamic collaboration for interorganizational enterprises [52]. Payne et al. proposed a solution that incorporates Napoleon – a multilayered RBAC modeling environment for distributed computing systems [53] – in a WfMS [17]. Huang and Atluri introduced a Web-enabled WfMS called SecureFlow [54], with their work showing that the security specification and enforcement could be placed on top of an existing WfMS to provide security using RBAC. Park and Sandhu described how to use role information on the Web using smart certificates [55]. Their work showed that role information can be used to authorize Web-based transactions between a client and a Web server. Ahn et al. defined a simplified RBAC model to describe the security architecture to be applied to an existing Web-based WfMS [18]. Basin et al. combined unified modeling language (UML) and RBAC to protect process components [56]. They showed how to integrate their security modeling language SecureUML with UML process models. SecureUML is a UML-based language for modeling access control requirements that generalizes RBAC. Park and Hwang proposed an approach that supports RBAC services for collaborative enterprise in.

(36) 23. peer-to-peer computing environments, where the access control information is interpreted by a middleware among peers [57]. Chou et al. proposed an access control model for WfMSs named WfACL [19]. They focused on dynamically specifying role-subject and role-permission binding. In their paper they used the terms “dynamic role change” and “role association change”. WfACL should be embedded in a workflow to control access when a workflow instance is executing. Some researchers have studied the use of cryptography to secure WfMSs. The Meteor workflow system utilizes encryption algorithms, digital signatures, and access control, in which workflows are statically prepartitioned in the central server in a distributed CORBA-based system [58,59]. Hwang et al. proposed a WfMS that operates in a purely distributed manner without needing a centralized workflow engine [60]. It is an XML-based document-routing system that implements major required security features such as authentication, confidentiality, data integrity, and nonrepudiation based on cryptographic algorithms in distributed or large-scale network environments. Previous work that has introduced the ACM, MLS, TBAC, RBAC, or cryptography to secure WfMSs has not addressed the goal of the CWSM; that is, avoidance of COI. One of the proposed access control models is called attribute-based access control (ABAC) where the central idea asserts that access can be determined based on various attributes presented by a subject [61]. UCON is a kind of ABAC model where authorizations are predicates defined on subject and object attributes, while conditions are environmental restrictions represented by system attributes, such as time, location, load, etc [62]. Authorizations and conditions are enforced not only when a subject generates an access request, but also during the whole ongoing stage of the usage session..

(37) 24. As the side-effects of the usage, subject and object attributes can be updated; this is referred to as attribute mutability in UCON. Kuhn et al. summarized access control schemes which employ attributes to determine the permission of accesses into several models including ABAC-basic, ABAC-RBAC hybrid, ABAC-ID, RBAC-A (dynamic roles), RBAC-A (attribute-centric), and RBAC-A (role-centric) [63]. Yao et al. proposed the RCBAC model which extends the RBAC with context constraints [64]. The RCBAC mechanisms dynamically grant and adapt permissions to users based on a set of contextual information collected from the grid environments. Strembeck and Neumann presented an approach that uses special purpose RBAC constraints to base certain access control decisions on context information [65]. A context constraint is defined as a dynamic RBAC constraint that checks the actual values of one or more contextual attributes for predefined conditions. ABAC and context-based RBAC provide dynamic characteristic. If we want to implement CWSM in ABAC or context-based RBAC, the run-time history of data accesses and company information should be represented as attributes or context in the access control system and the access control system should be able to encode BN read and write rules. There has been little work on implementing the CWSM in WfMSs. Sandhu proposed to employ the lattice model to implement the CWSM [66]. Lattice labels which are actually access arrays and are used to record the access history need to be associated to all the subjects and objects. He thought that the BN model is too restrictive and did not discuss how to enforce the BN write rule in the lattice model. Also, there is no discussion about how to apply the CWSM in WfMS. Atluri et al. extended the CWSM for decentralized workflow execution [67]. They impose access restrictions on.

(38) 25. sensitive data by restrictive partitioning, which ensures that no two task agents of the same COI class are in one partition. However, their partitioning scheme requires the binding of subjects and companies to be static. The preliminary result of this research is published in [68]. We extended it in this paper including related work, more examples and discussion, and general access control model.. 2.2 Related works of DRA4WfMS Distributed and decentralized execution of workflows is a mandatory requirement for complex, large-scale applications for workload partitioning and for consistency with the desire for organizational decentralization. This requires distributed WfMSs, with activities in a single workflow process generally being distributed into multiple workflow engines located in different machines. Process instances are still stored in these workflow engines, and participants connect to them to execute activities. Alonso et al. presented a distributed architecture, Exotica/FMQM, for WfMSs [69]. Their approach eliminated the need for a centralized database by using persistent messages, with each workflow engine functioning independently of the other engines, and the only interaction between engines being via persistent messages that informed about the completion of execution of the process steps. Ceri et al. showed how to implement a distributed WfMS by using a distributed object model (CORBA) and client/server architecture [6]. Muth et al. developed a partitioning algorithm for a centralized WfMS for distributed execution, with a synchronization scheme that guarantees the correct and efficient synchronization between the workflow engines [7]. Schuster et al. presented an approach to improve the scalability of a WfMS to the enterprise structure by explicitly.

(39) 26. capturing the WfMS configuration [8], where the units being distributed are subworkflows. Bauer and Dadam proposed how to minimize the load of the workflow engine by migrating workflow processes from one workflow engine to another [11]. Wietrzyk and Takizawa investigated how to support electronic commerce in a distributed WfMS [70]. They proposed that auxiliary functions were necessary for managing workflows in a distributed environment to support electronic commerce, including mechanisms for controlling the execution and monitoring the status of workflows designed on other WfMSs, on-line reclustering, a secure distributed workflow architecture, and efficient replication of workflow servers. Shegalov et al. proposed an XML-enabled architecture for distributed workflow management [71]. The key feature of their architecture is an XML mediator that handles the exchange of business and flow-control data between workflow and business-object servers on one side and client activities on the other side via XML messages over http. The use of an XML mediator means that none of the involved parties, clients, business-object servers, or workflow servers needs to know any details about the other parties. Tripathi et al. developed a methodology for building a distributed workflow systems using a high-level specification in XML and then interfacing this specification with mobile-agent-based middleware [72]. Their workflow plan is specified in XML in terms of shared objects, user roles, role-based security requirements, operations, and workflow requirements. The agent-based middleware interprets the XML description of the environment, and transparently launches agents to the nodes of other users when operations need to be performed to ensure workflow requirements. In general, the.

(40) 27. execution of activities must still be controlled by workflow engines that communicate with the participants in the above systems; they are all engine-based WfMSs. Document routing is an important problem in a document management system, which is the decision process for determining the best targets (e.g., a person or storage device) to receive a set of documents. Related approaches include relevance feedback approaches [73], learning techniques based on statistical classification [74,75], and business routing logic [76], which address the issues of designing an algorithm for efficiently and correctly routing documents. In this dissertation we have designed a document-routing system for a WfMS in which the routing scheme is explicitly defined by the workflow designer. Previous studies have investigated document routing in a WfMS. Kumar and Zhao developed a language that supports the routing of workflow for Internet-based electronic commerce services [77]. This language, called Extensible Routing Language (XRL), provides support for routing documents and managing workflows between trading partners. A routing slip described in XRL contains a sequence of addresses (or users) to which a document must be sent. Document and routing histories are embedded in the routed document. The distributed workflow engines are responsible for communicating with the participants. For security reasons, the system is able to decrypt and encrypt documents and routing slips. However, the XRL framework does not include a mechanism to support nonrepudiation of process execution. Montagut and Molva presented a document-routing-based security solution to support the secure execution of distributed workflows [78]. Their scheme employs the onion encryption technique [79,80] to ensure the integrity of the distributed execution of workflows. The scheme.

(41) 28. employs two types of cryptographic keys: (1) the policy keys, which are managed by the policy key server and are used to protect (2) the vertex keys, which are used to protect the workflow data. In their initial work they constructed an onion structure with vertex private keys to assure the integrity of the workflow execution. However, their system includes the following limitations: (1) the flow control must be static because the static onion structure has to be constructed according to the flow control of the execution of workflow process, and hence it cannot support branch and loop structures in the workflow process, (2) participants who do not share the same policy key cannot check or read the execution result of others because they cannot obtain the vertex keys of others, and (3) some vertex keys must be duplicated in the onion structure in order to support AND-split and AND-join commands in the flow control. Our scheme does not suffer from these limitations. The preliminary document-based WfMS that we proposed previously [60] suffers from the limitations of (1) only considering the basic operational model and not supporting workflow monitoring, and (2) needing the workflow designer to specify how to embed a digital signature and sign the execution result of workflow execution; it therefore cannot guarantee nonrepudiation. Other work in the area of mobile code security is also relevant to the present study. Mobile agent technology provides a computing paradigm in which a software agent can suspend its execution on a host computer, transfer itself to another agent-enabled host on the network, and resume execution on the new host. This technology presents significant new security threats from malicious agents and hosts. Obvious approaches to solve this problem include restricting agents to fixed itineraries within a network of trusted platforms and restricting agents to travel via only one authenticated hop away from.

(42) 29. home. Several approaches have been proposed. State appraisal [81] involves ensuring that an agent has not been somehow subverted due to alterations of its state information. Appraisal functions are used to determine what privileges to grant an agent, based on whether identified state invariants hold. The approach taken by proof-carrying code [82] obligates the code producer to prove formally that the program possesses safety properties that have previously been stipulated by the code consumer. The code and proof are sent together to the code consumer where the safety properties can be verified. The structure of the proof makes it straightforward to verify without using cryptographic techniques. Our scheme employs a cascade-based method to embed digital signatures to fulfill similar goals as in state appraisal and proof-carrying code. The use of path histories [83,84] involves having an agent maintain a verifiable record of the prior platforms visited, so that a newly visited platform can determine whether to process the agent and what resource constraints to apply. Execution tracing [85] is a technique for detecting unauthorized modifications of an agent (including to its state) by faithfully recording the behavior of the agent during execution at each agent platform. Our scheme supports both path histories and execution tracing. However, we have also considered related dynamic security requirements for displaying this information and its effect in document routing [86]. There has been a considerable amount of work on WfMS security. Kumar and Zhao investigated how to support control and authorization in a WfMS using three techniques: workflow-control matrix, imposing and enforcing constraints on the routing sequence, and event-based constraints [87]. Role-based access control (RBAC) [15] has been employed to implement an access-control mechanism in a WfMS. Atluri and Huang.

(43) 30. proposed a workflow authorization model that allows the subjects to gain access to required objects during the execution of a specific task [51]. The authorization can be synchronized with the execution of the workflow process. Bertino et al. presented a language for defining constraints on role assignment and user assignment to tasks in a workflow that allowed the separation of duties to be specified in a WfMS [16]. The many studies that have addressed workflow security issues have generally focused on access control and separation of duty issues. Park et al. addressed the security services for a secure workflow system to support dynamic collaboration for inter-organizational enterprises [52]. Payne et al. proposed a solution that incorporates Napoleon into a WfMS [17], which is a multilayered RBAC modeling environment for distributed computing systems [53]. Huang and Atluri introduced a Web-enabled WfMS called SecureFlow [54], which showed that the security specification and enforcement could be added to an existing WfMS to provide security with the notion of RBAC. Park and Sandhu described how to use role information on the Web using smart certificates, and showed that role information can be used to authorize Web-based transactions between a client and a Web server [55]. Ahn et al. defined a simplified RBAC model to meet the needs and describe the security architecture to be applied to an existing Web-based WfMS [18]. Basin et al. combined UML and RBAC to protect process components [56]. They presented the SecureUML security modeling language and showed how to integrate it with UML process models. SecureUML is a UML-based language for modeling access-control requirements that generalizes RBAC. Park and Hwang proposed an approach that supports RBAC services for collaborative enterprise in peer-to-peer computing environments [57], where access-control information is.

(44) 31. interpreted by middleware that operates among peers. Chou et al. proposed an access-control model for a WfMS named WfACL [19]. They focused on giving the model the ability to specify dynamic role–subject and role–permission binding, and they used the terms “dynamic role change” and “role association change” in their paper. WfACL should be embedded in a workflow to control access when a workflow instance is executing. Hsiao and Hwang proposed a security-policy language for situations in which the RBAC model is not sufficient to implement the Chinese-wall security model [68]. These architectures use the access-control model, which provides a basis for the security policies of secrecy and integrity. The objects in these systems are resources such as files, devices, and processes, and the clients are entities that make requests to perform operations on objects. An access-control server that acts similarly to a workflow engine represents a guard that decides whether or not to grant each request based on the client making the request, the operation requested, and the access rules for the object. In contrast, the operational model of the DRA4WfMS does not contain an access-control server to monitor the access control during the workflow execution. We therefore cannot apply these schemes directly to fulfill the security requirements of the DRA4WfMS.. 2.3 Related works of DRA4SOA Existing SOA security standards such as WS-Security [88], Security Assertion Markup Language (SAML) [89], WS-Trust [38], WS-SecureConversation [90], and WS-SecurityPolicy [37] focus on the message security and identity management of SOA implementations that use Web services. These standards were created to address message-level security and provide the ability to satisfy security requirements of an.

(45) 32. SOA environment. However, they only support the point-to-point security requirements of individual services, and they cannot refer to the structure of dynamically formed calling chains (or service chains [91, 92, 93]) to perform access control for a service invocation. Access control is a mechanism that enables an authority to control accesses to a given information system. Many access control mechanisms have been proposed and implemented. Access control is traditionally implemented using an access control matrix, where an access request from a subject can be granted if the requested access right is recorded in the matrix [14]. A similar access control model is the access control list (ACL), which is usually implemented as a list of permissions attached to a file or object in a computer file system [94]. The role-based access control (RBAC) model differs from ACLs used in traditional discretionary access control systems in that it assigns permissions to specific operations that have high-level meaning in the organization, rather than to low-level data objects [15]. The Extensible Access Control Markup Language (XACML) is an open-standard XML-based language designed to express security policies and access rights to information for Web services, digital rights management, and enterprise security applications [95]. The XACML is an access control model that incorporates the RBAC model, and it was designed to work in conjunction with the SAML [89]. Recent work in attribute-based access control (ABAC) [96] suggests that attributes and rules could either replace RBAC or increase its simplicity and flexibility. A variant of ABAC is the context-aware access control system that can dynamically adjust role assignments and permission assignments based on context information [97]..

(46) 33. Some researches have focused on the security problem in service composition in SOA systems. Zhu et al. proposed an access control model for Web-service provision called ACM4WSC, in which the users can access a composite Web service without being concerned about the access control of its elementary services [98]. They presented two methods to manage the access control policies of the elementary services. Carminati et al. proposed a method for modeling security constraints and a brokered architecture to build composite Web services according to specified security constraints [99]. Bartoletti et al. proposed a static approach that employs -calculus to determine how to compose services while guaranteeing that their execution is always secure without requiring any dynamic checking [100]. Srivatsa et al. presented an access control model for specifying and enforcing access control rules on the provision of Web services [101]. They proposed using pure-past linear temporal logic to perform history-sensitive access control based on causal or temporal dependencies of logged transactions. Hwang et al. proposed an operational model to support the security of Web services [102]. Their model supports a flexible key specification scheme called explicit key definition, which can be used to define three types of keys: static keys, dynamically selected keys, and keys applied to digital signatures. The service requester can determine the identity of the keys used without having to negotiate with the service provider. Paci et al. proposed a novel approach for determining at design time whether a choreography can be implemented by a set of Web services based on their access control policies and the disclosure policies regulating the release of their credentials [103]. Chiang proposed a framework to support process-instance security in an SOA, which targeted how to serialize the process instance of BPEL [104]. Wu-Lee and.