雲端環境中為服務導向架構支援安全性，可信任及協同合作

全文

(1)國立臺灣師範大學資訊工程研究所博士論文. 指導教授：黃冠寰. 博士. 雲端環境中為服務導向架構支援安全性，可信任及協同合作. Support Security, Trust, and Collaboration for SOA System in the Cloud. 研究生：中華民國. 吳李祺一零三. 撰年. 八. 月.

(2) 摘要隨著服務導向架構(SOA)及雲端運算等技術的誕生，網路應用迎接了革命性的演進，除了發展出在 Web 以及雲端環境的新系統及軟體外，也同時產生了需要面對的新問題，使得近代的資訊工程領域有了新的研究方向，例如: 服務導向架構的安全性設置，雲端服務的可信任性以及協同合作，執行流程的同步控制等。在服務導向架構處理安全性及權限控制相關的標準規範中，並沒有設計如何與整個 SOA 系統的整合應用，此論文中提出了兩個新的語言，能使系統開發者動態且有效地部署其安全性策略到系統中的 Web 服務上。除了安全性問題之外，我們也發現傳統資料庫系統的 ACID 特性，在 SOA 系統中是需要被釋放的，我提出了一個新的架構，能有效的同步控制複數的執行流程在整個系統中的運作狀態，且支援其同步控制規則的動態更新。協同合作是雲端服務中一個新的應用，它讓使用者們可以透過網路來異地共同編輯一份文件或交換意見，此論文提出了一個新的工作流程描述語言及雲端服務，使用者能透過語言來提出需求，並提交給服務來共同定義一個工作流程。一個雲端服務是否值得相信，需要有辦法能證明參與者們是否有違反的行為，除了數位簽章提供的不可否認性外，我發現還需要確保雲端資源存取的循序性，才能消除資源在大量使用時可能發生的爭議，此論文最後提出一個新的溝通協議，能證明服務提供者是否有違反循序性，來確保此雲端服務是值得相信的。關鍵字：服務導向架構，Web 服務，業務過程執行語言，安全性策略，存取控制模型，雲端協同合作，同步控制，可廢止邏輯，工作流程描述語言，不可否認性，循序性，證明違約 i.

(3) Abstract With the birth of Cloud and service-oriented architecture (SOA), there are various new issues discovered in computer science and information engineering domain, for example: the deployment of security and access control policies and the concurrency control of long-running transactions in SOA system, the cloud collaboration of defining a workflow definition, and the proof of violations of services in the cloud. The related security and access control standards of Web service lack the integration with SOA system. This paper proposed two new languages to help the system developer dynamically deploy the security and access control policies. The separate of concern is convenient for the administrator to handle the quality of system. A transaction of SOA system needs to relax the ACID properties since it can be long-running. A proposed new model can deal with the concurrent control of them by exploring the global context, and support the dynamic modification of control rules. We also proposed a novel language for defining workflow in the working model of cloud collaboration. The language enables the distributed definition and concurrent revision of a workflow by multiple users from different places in the cloud. For a trustworthy cloud service, it is necessary to have a scheme to detect or proof any probable violation from transaction participants. In the last topic of this paper, we proposed a novel scheme which can let SOA system provide the non-repudiation and serializability. Users and the service provider exchange attestations for every request. The user only has to store the last attestation it received, and the service provider keeps all the attestations, so that they can be used when proving is required. Key words: SOA, Web Services, BPEL, security policy, access control model, cloud collaboration, concurrency control, defeasible logic, Workflow definition language, nonrepudiation, serializability, proof of violation. ii.

(4) 誌謝感謝黃冠寰老師在這五年中的教導，讓我十分的有收穫，老師教我對事要能判斷真偽、實事求是，不可一味地相信片面看到的東西，抽絲剝繭過後往往剩下的只是一個很簡單的道理，正所謂大道至簡。透過與老師的討論，讓我在敘述以及表達能力上有很顯著的提升，並且引導我尋找問題以及解決問題，這幾年從老師身上學習到的經驗是十分寶貴的。也感謝我的父母親在這段日子中的全力支持，使我能更專注在課業以及研究上，並順利取得博士學位。另外，還要感謝學長與這幾年共事過的同學及學弟，感謝哲生學長、宇程學長以及多位學弟們，大家有緣在同一間實驗室，彼此協助，彼此激勵，最後都順利畢業，往人生下一個階段邁進。感謝我的後學們，你們讓實驗室變得更加活潑，希望實驗室的大小事情能夠傳承下去。最後，感謝這七年來陪著我一起成長的佩珊，妳讓我在面對各種困難時都不輕易選擇逃避及放棄。我會不斷地前進，努力挑戰更高的成就，謝謝大家。. 吳李祺. 誌於. 國立臺灣師範大學資訊工程研究所民國一百零三年八月. iii.

(5) Table of Contents Chapter Title Page 摘要................................................................................................................................ i Abstract ........................................................................................................................... ii 誌謝.............................................................................................................................. iii Table of Contents ........................................................................................................... iv List of Tables .................................................................................................................. vi List of Figures ............................................................................................................... vii Chapter 1. Introduction ................................................................................................... 1 Chapter 2. A Framework and Language Support for Dynamic Security Policy in Service-Oriented Architecture ................................................................................ 4 2-1. Motivating examples ....................................................................................... 6 2-2. Related work .................................................................................................. 11 2-3. The DPSL ...................................................................................................... 13 2-4. Architecture to support the DPSL in the BPEL run-time system .................. 21 2-5. Implementation and experiments................................................................... 26 Chapter 3. Transient Policy to Support Dynamic Access Control in Service-Oriented Architectures and Workflow Management Systems ............................................. 29 3-1. Motivating examples ..................................................................................... 34 3-2. WBDAC model ............................................................................................. 37 3-3. Specifying dynamic access control in the DACL4SOA ................................ 42 3-4. Architecture to support the DACL4SOA in the BPEL run-time system ....... 52 3-5. Implementation and experiments................................................................... 58 3-6. Related work .................................................................................................. 62 Chapter 4. Concurrency Control of Long-Running Autonomous Transactions by Exploring the Global Context ............................................................................... 67 4-1. A motivating example .................................................................................... 71 4-2. The concurrency control model ..................................................................... 74 4-3. A programming language for concurrency control ........................................ 77 4-3-1. Introduction to defeasible logic .......................................................... 77 4-3-2. The DLCCL ........................................................................................ 79 4-3-3. Predicates, functions, and variables in the DLCCL ........................... 83 4-3-4. Examples to demonstrate the activation of DLCCL codes ................ 84 4-4. Architecture of the CCS to support the DLCCL............................................ 87 4-5. Implementation and experimental results ...................................................... 90 4-6. Distributed synchronization in the DLCCL................................................... 93 iv.

(6) 4-7. Previous work ................................................................................................ 94 Chapter 5. Workflow Definition by Cloud Collaboration ............................................. 97 5-1. A definition language for collaboration workflow definitio n ............................................................................................................................. 105 5-2. Conflicts between CLWfDL Rules .............................................................. 112 5-3. Distributed Definition and Concurrent Revision in the CLWfD L ............................................................................................................................. 114 5-4. The CLWfDL Document and API ............................................................... 116 5-5. Related work ................................................................................................ 120 Chapter 6. POV Schemes for SOA Systems ............................................................... 123 6-1. A new protocol from C&L for SOA ............................................................ 127 6-2. Architecture of C&L and DoubleC schemes for SOA................................. 132 6-3. Implementation and experimental results .................................................... 134 6-4. Related work ................................................................................................ 138 Chapter 7. Conclusion and Future Work ..................................................................... 141 References ................................................................................................................... 145 Appendix A ................................................................................................................. 155. v.

(7) List of Tables Table 2-1: Code sizes of the Motivation-1 WSDL and BPEL documents .................... 27 Table 2-2: Code sizes of the Motivation-2 WSDL and BPEL documents .................... 27 Table 2-3: Execution time of the original and translated BPEL processes of Motivation-1 and Motivation-2............................................................................. 28 Table 3-1. Comparison of translated BPEL and original BPEL processes ................... 60 Table 3-2. Comparison of translated BPEL and original BPEL processes ................... 60 Table 3-3. Execution Time of activating and deactivating the transient policies ......... 61 Table 4-1: Variable tables .............................................................................................. 85 Table 5-1. The activities of the workflow ................................................................... 100 Table 5-2. The Workflow Requirements of Alice, Peter, John, and Bruce ................. 101 Table 5-3. Running times for processing some CLWfDL documents ........................ 119 Table 6-1: Sizes of chained ACK messages (|ACK| is the number of messages) ....... 135 Table 6-2: Times (in ms) required to prove the legality of a sequence of ACK messages ............................................................................................................................. 135 Table 6-3: Average times (in ms) required to perform an operation with the plain scheme, C&L scheme, and DoubleC scheme for individual resource ................ 136 Table 6-4: Average and maximum times (in ms) required to perform operation with the plain scheme, C&L scheme, and DoubleC scheme for random resources ......... 137. vi.

(8) List of Figures Figure 2-1. The original BPEL process in the first motivating example ........................ 7 Figure 2-2. The modified (A) and worst-case (B) BPEL processes in the first motivating example ................................................................................................. 9 Figure 2-3. The original BPEL process in the second motivating example .................. 11 Figure 2-4. The modified BPEL process in the second motivating example ................ 11 Figure 2-5. An SOA application with dynamic policies ............................................... 15 Figure 2-6. The architecture of a DPSL document ....................................................... 16 Figure 2-7. The syntax of the dynamic policy specifier ............................................... 18 Figure 2-8. The DPSL documents for the first (A) and second (B) motivating examples ............................................................................................................................... 21 Figure 2-9. The operation of the DPSL translator for the BPEL .................................. 22 Figure 2-10. The algorithm which performs the DPSL transformation ........................ 24 Figure 2-11. The original and translated BPEL for the example in Algorithm 2-1 ...... 25 Figure 2-12. The translated BPEL for the first motivating example............................. 25 Figure 2-13. The translated BPEL for the second motivated example ......................... 26 Figure 3-1. Operation of ABAC.................................................................................... 32 Figure 3-2. Sample scenario consisting of two BPEL processes .................................. 35 Figure 3-3. Operation of WBDAC ................................................................................ 41 Figure 3-4. An SOA application with dynamic access control policies ........................ 43 Figure 3-5. Structure of a DACL4SOA document........................................................ 43 Figure 3-6. Syntax of the transient policy specifier ...................................................... 46 Figure 3-7. An example transient policy specifier section ............................................ 50 Figure 3-8. Operation of the DACL4SOA transformer for the BPEL .......................... 53 Figure 3-9. An SOA with a dynamic access control mechanism .................................. 54 Figure 3-10. Backus-Naur Form of the policy enforcement command ........................ 55 Figure 3-11. A SOAP message with a policy enforcement command .......................... 56 Figure 3-12: A SOAP message that requests a PAP to add a policy ............................. 57 Figure 4-1. Example of a dependency between two transactional processes. .............. 72 Figure 4-2. Example of a conflict matrix ...................................................................... 73 Figure 4-3. Illustration of the concurrency control model ............................................ 75 Figure 4-4. The state transition diagram of a transaction ............................................. 76 Figure 4-5. Examples of DLCCL codes ........................................................................ 79 Figure 4-6. Examples of DLCCL codes ........................................................................ 82 Figure 4-7. Architecture of the CCS ............................................................................. 87 Figure 4-8. Average execution time for entry and commit operations (with three vii.

(9) transactions) .......................................................................................................... 92 Figure 4-9. Average execution time for entry and commit operations (with six transactions) .......................................................................................................... 92 Figure 4-10. Average execution time for entry and commit operations (with twelve transactions) .......................................................................................................... 93 Figure 4-11: Examples of DLCCL codes to implement the semaphore ....................... 94 Figure 4-12. BusinessAgreement With Coordinator Completion abstract state diagram of WS-BusinessActivity........................................................................................ 96 Figure 5-1. Traditional way to define a workflow process by multiple users ............. 100 Figure 5-2. A sample workflow definition .................................................................. 103 Figure 5-3. Cloud collaboration of the workflow definition....................................... 103 Figure 5-4. Example CLWfDL rules ........................................................................... 106 Figure 5-5. An AND-join construct ............................................................................ 106 Figure 5-6. Illustration of Algorithm 5-1 .................................................................... 111 Figure 5-7. The result of applying Algorithm 5-1 to Γ ............................................... 114 Figure 5-8. The directed graph generated by revised CLWfDL rules ......................... 115 Figure 5-9. Syntax of the CLWfDL document ............................................................ 117 Figure 5-10. Two example CLWfDL documents ........................................................ 117 Figure 5-11. Codes invoking the CLWfDL API ......................................................... 118 Figure 5-12. Node and edge sets obtained by processing the CLWfDL documents in Figure 5-10 .......................................................................................................... 119 Figure 6-1: Messages for five operations of the same resource in DoubleC scheme . 130 Figure 6-2: Architecture of C&L and DoubleC scheme for Web service ................... 132 Figure 6-3: The SOAP message with WS-security ..................................................... 134. viii.

(10) Chapter 1. Introduction Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed services that may be under the control of different ownership domains [1]. A service is a self-contained unit of functionality, such as retrieving an online bank statement. Services can be combined by other software applications to provide the complete functionality of a large software application. SOA provides a uniform means of offering, discovering, and interacting with and using services to produce desired effects consistent with measurable preconditions and expectations. Implementers commonly build SOAs using web services standards (for example, SOAP) that have gained broad industry acceptance after recommendation of Version 1.2 from the W3C [2] (World Wide Web Consortium) in 2003. A service-oriented architecture (SOA) is a useful technical platform for implementing a workflow management system (WfMS). Security policies and access control usually has to be regulated according to the dynamic behaviors in the execution of workflow processes in SOA systems since different workflow process instances of the same workflow process definition may exhibit different dynamic behaviors. It is necessary to simultaneously support both dynamic security policies and separation of concerns when developing an SOA application. The access control that can be fulfilled using role-based access control (RBAC) and attribute-based access control (ABAC) models is also insufficient in SOA systems since these models do not consider the dynamic behaviors of workflow processes. A transactional Web-based process is usually a long-running process that may contain multiple activities. A transactional process is a workflow process that should be executed as if no other process was executing concurrently and as if there were no 1.

(11) 2. failures [84]. The isolation property is commonly relaxed to obtain efficient concurrent execution of distributed transactions, which makes concurrency control crucial for ensuring the reliable execution of long-running autonomous transactions in SOA system. Previous studies on relaxing the isolation property of transactions proposed deriving the conflict relation between each pair of autonomous transactions so as to construct a dependency graph that would be used to decide whether the execution of transactions has to be compensated to ensure the atomicity of transactions in the presence of transaction failures. In this paper we show that the pairwise conflict relation is not sufficient in the general cases and propose a solution for implementing concurrency control dynamically according to the global context of all of the autonomous transactions in the system Cloud collaboration technologies allow users to upload and edit documents or objects within the cloud. A traditional workflow definition language is not possible for distributed definition and concurrent revision of a workflow by multiple users from different places in the cloud. Users who participate in defining a workflow just can specify their own requirements for the workflow execution. Each user can selectively contribute to part of the workflow definition. Any conflicts between the requirements of different users should be detected automatically. A single flow-control construct such as AND-join or OR-split should incorporate the requirements of multiple users. As SOA services are opened up, it is necessary to consider how to combine these services securely [11]. Several emerging technologies and standards address different aspects of the problem of security in SOA. For example, standards such as WS-Security [12], SAML [13], WS-Trust [14], WS-SecureConversation [15], and WS-SecurityPolicy [16] focus on the security and identity management of SOA implementations that use Web services. These standards have been created to address.

(12) 3. message-level security within an SOA environment. Although these standards provide the ability to satisfy security requirements such as authentication, confidentiality, data integrity, and nonrepudiation, they cannot offer a proof of violation (POV) for serializability and freshness of transactions execution. This paper is organized as follows: Chapter 2 presents the dynamic policy specification language (DPSL) for managing and controlling the security according to the dynamic behavior of the workflow in SOA, Chapter 3 presents the workflow-based dynamic access control (WBDAC) for SOA and workflow-based systems, Chapter 4 presents a solution for implementing concurrency control dynamically according to the global context of all of the autonomous transactions in the SOA system, Chapter 5 presents the cloud collaboration workflow definition language (CLWfDL) for defining workflow in the working model of cloud collaboration, Chapter 6 presents a new scheme which guaranatees POV of non-repudiated and serialized transactions of SOA system, conclusion and future work are drawn in Chapter 7. These works presented in this paper have been accepted for publication in corresponding journals and conferences [3, 4, 5, 6, 7]..

(13) Chapter 2. A Framework and Language Support for Dynamic Security Policy in Service-Oriented Architecture Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed services that may be under the control of different ownership domains [1]. 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. SOA separates functions into distinct units, or services [8], which developers make accessible over a network so that users can combine and reuse them when producing applications. These services communicate with each other by exchanging data or by coordinating an activity between multiple services. The SOA can be implemented by a software system such as Web services [8]. Web services 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. One of the goals of SOA is to allow users to combine various functionalities to form ad-hoc applications that are almost entirely developed from existing software services. Orchestration is normally required to produce a new application [9]. A high-level language such as the BPEL extends the service concept by providing a method for defining and supporting the orchestration of fine-grained services into more coarse-grained business services [10]. Orchestration involves ensuring that Web services interact with each other at the message level, including the business logic and execution order of the interactions from the perspective and under 4.

(14) 5. the control of a single endpoint. This involves an executable business process that may result in a long-lived, transactional, multi-step process model. In fact, the BPEL incorporates a workflow model to describe the orchestration of Web services. As SOA services are opened up, it is necessary to consider how to combine these services securely [11]. In many business domains, Web services must exhibit quality attributes such as robustness, security, and maintainability. Several emerging technologies and standards address different aspects of the problem of security of services in SOA. For example, standards such as WS-Security [12], SAML [13], WS-Trust [14], WS-SecureConversation [15], and WS-SecurityPolicy [16] focus on the security and identity management of SOA implementations that use Web services. These standards have been created to address message-level security and provide the ability to satisfy security requirements within an SOA environment. However, these standards only support the static specification or description of the security requirements in an SOA environment. As mentioned above, services require orchestration to produce a new application. The BPEL demonstrates that a workflow model is necessary when performing the orchestration. However, the execution of a workflow-based system is intrinsically dynamic. For example, the branching that occurs during workflow execution may depend on the values of certain variables in a process instance, and the presence of branching in a previous execution may influence the subsequent execution. This makes it necessary to investigate if statically specifying the security policy requirement fulfills the requirements of the workflow-based SOA environment. In this chapter we first present several motivating examples to demonstrate that if the security policy requirement cannot be specified according to dynamic behavior in a workflow-based SOA system, then the resulting overly tight coherence between the.

(15) 6. Security policy requirement and the flow structure will increase the difficulty, overhead, and cost of system development and maintenance. According to the separation-of-concerns principle, implemented Web services should only provide the core required functionality. Herein we (1) propose the concept of dynamic policies for SOA systems, (2) describe the architecture to support dynamic policies in the BPEL, and (3) define a language called the dynamic policy specification language (DPSL) to support the proposed architecture. Although the DPSL is designed to cooperate with previously proposed standards for SOA architecture, such as the WSDL, the BPEL, WS-Security, WS-Policy, WS-SecurityPolicy, and WS-ReliableMessaging, we believe the method of incorporating dynamic policies into SOA using the DPSL can be applied to any SOA architecture. Therefore, we can separate the specification of the security policy requirement and service orchestration so as to reduce the software development and maintenance cost of an SOA system. The implementation and experimental results presented here demonstrate the feasibility of the proposed architecture. This chapter is organized as follows. In Section 2-1 we present examples to show that statically specifying the security policy requirement is insufficient. Section 2-2 surveys previous work on Web-services framework and related work which tried to extend it. In Section 2-3 we present the syntax and semantics of DPSL. The architecture to support DPSL in BPEL is given in Section 2-4. In Section 2-5 we show the implementation and experimental results.. 2-1. Motivating examples In this section we present examples to demonstrate that statically specifying the security policy requirement is insufficient. Without loss of generality, we use the BPEL, WS-Security, and WS-SecurityPolicy to construct our demonstration example..

(16) 7. Figure 2-1 shows the first example, which is a BPEL process. Assume that it is part of the military supply system. The “Client”, “Inventory Query Service”, and “Registration Service” are external Web services. The basic security requirement in preliminary system development is that the communication between the process and external Web services should be protected by the mechanism supported by WS-SecurityPolicy. Assume that the security policies between the three external Web services are defined by SP1, SP2, and SP3 as shown in Figure 2-1. SP1, SP2, and SP3 define the communication security requirements for Web-services transaction in WS-SecurityPolicy, and are bound to the three bindings of the three Web services separately. The process consists of several activities: . Activity A1. This receives the supply requirement from the “Client”, and contains the amount and number of items.. . Activity A2. This checks the inventory of the item received in activity A1 by invoking an external Web service.. . Activity A3. This sends the actual supply requirement to the supply depot and registers it.. . Activity A4. This replies to the “Client”.. Client. binding SP3. A1. A2. A3. Inventory query Service binding portType SP1. Register service binding portType SP2. : partnerLink A4. : partnerLinkType. WSDL. BPEL. The original BPEL for the first motivating example.. Figure 2-1. The original BPEL process in the first motivating example.

(17) 8. Assume that the security requirement has to be changed after its first deployment. Since inventory information is confidential in a military supply system, the authority decides that activity A2 should not communicate with “Inventory query services” with security policy SP1 directly. The new requirement is that the security policy should be selected according to the category of the item obtained in activity A1. The items are classified into two categories, each with different security policies in communicating with the “Inventory query service”. Assume that the two security policies are SP1 and SP1. Different security policies have different cryptographic algorithms and keys. WS-Policy supports policy alternatives, which allows us to specify a set of policies from which the service client can choose one policy arbitrarily [17]. However, since WS-Policy does not support switching security policies according to the dynamic behavior of the BPEL process directly, the system developer needs to change the original BPEL process according to the new security requirements. Figure 2-2A shows the modified BPEL process, which adds an “if” activity B1 that decides how to pick the security policies according to the item category obtained in activity A1. If the appropriate security policy is SP1, B1 controls the flow to execute activity C1; otherwise B1 controls the flow to proceed to C2. Note that C1 and C2 are activities that specify the corresponding binding1 of the partnerLink of A2. Furthermore, if the authority needs to add more security policies for the communication to the “Inventory query service”, the system developer needs to add more activities to the BPEL process, as shown in Figure 2-2B. We can see that the security requirement depends on the dynamic behavior of the BPEL process since it depends on the data received in activity A1. Also, the structure of the BPEL process itself needs to be modified when the. 1 Actually, it specifies the endpoint reference to the partner of the partnerLink. The endpoint reference belongs to a port and the port belongs to a binding that is associated with the portType of the partner [18-21]..

(18) 9. security requirement changes. The resulting tight coherence between the structure of the BPEL process and the security requirement makes the system difficult to design and maintain. Below we give another example to demonstrate another kind of dynamic behavior that the security requirement may depend on.. Client. binding SP3. A1 B1. True. If else. Inventory query Service binding1 SP1’ portType binding2 SP1’’. C1 C2. A2. Register Service binding portType SP2. A3 : partnerLink A4. : partnerLinkType BPEL WSDL. The modified BPEL for the first motivating example.. (A) Client. binding SP3. A1 B1. If. False. ... else. True. Inventory query Service binding1 SP1’. C1. else If. C2. .... binding2 SP1’’. Cn. : partnerLink. A3. : partnerLinkType WSDL. BPEL. .... .... A2. portType. bindingn SP1n Register Service binding portType SP2. A4. The worst-Case BPEL for the first motivating example.. (B) Figure 2-2. The modified (A) and worst-case (B) BPEL processes in the first motivating example The second example is similar to the first example. However, we now have two.

(19) 10. “Inventory query service” Web services for different items received in activity A1. Referring to Figure 2-3, the process consists of several activities: . Activity A1. This receives the supply requirement from the “Client”, and contains the amount and number of items.. . Activity D1. This checks the inventory of the item received in activity A1 and decides to branch to either A2 or A3 to invoke the applicable external Web service.. . Activities A2 and A3. These invoke different external Web services.. . Activity A4. This sends the actual supply requirement to the supply depot and registers it.. . Activity A5. This replies to the “Client”. Similar to the previous example, assume that the security requirement has to. change after its first deployment. The new requirement is that activity A4 can communicate with the register services using different security policies according to the previous flow control of the BPEL. This depends on the execution of activity D1. If activity A2 was executed, then activity A4 uses security policy SP2; otherwise it should use policy SP2. Figure 2-4 shows the modified BPEL process. Note that C1 and C2 in D2 are used to select an appropriate binding of the partnerLink for A4. Client. binding Policy. A1. D1. Inventory query service 1. If. else. True. A2. A4. : partnerLinkType. portType. Inventory query service 2 binding portType Policy. A3. : partnerLink. binding Policy. Register Service binding portType SP2. A5 BPEL. WSDL The original BPEL for the second motivating example..

(20) 11. Figure 2-3. The original BPEL process in the second motivating example Client. binding Policy. A1 D1. If else. True. A2. Inventory query service 2 binding portType Policy. A3. D2. If else. True. C1. C2. : partnerLink. : partnerLinkType A4. WSDL. BPEL. Inventory query service 1 binding portType Policy. Register Service binding1 SP2’ portType binding2 SP2’’. A5. The modified BPEL for the second motivating example.. Figure 2-4. The modified BPEL process in the second motivating example In the two motivating examples, the appropriate security policy cannot be determined until after the BPEL starts executing. In the first example, applying the security policy depends on the parameters received in activity A1, whereas in the second example the security policy should be enforced according to the flow control of the BPEL process. The situation is more complicated since the security policy depends on the computation result of the BPEL process, given that activities can perform sophisticated computations. An intuitive solution is to encode the security requirement in the implementation of the BPEL process, but then the BPEL process would have to be modified when the security requirement changes, and vice versa. This tight coherence between the BPEL process and its security policy increases the cost of implementing and maintaining the SOA application.. 2-2. Related work The main work related to the present study is the Web-services policy framework (WS-Policy) [17], which is an industrial specification standardized by the World Wide Web Consortium (W3C). WS-Policy defines a policy as a collection of policy.

(21) 12. alternatives, each of which is a collection of policy assertions. New policies can be defined to satisfy the needs of specific domains if these are not already included. Tosic et al. extended WS-Policy by introducing WS-Policy4MASC, which uses four new types of policy assertions: “goal”, “action”, “utility”, and “meta” [22]. The primary intent of this approach is to specify monitoring and control policies. The policy assertions define actions to be taken—such as the removal, addition, replacement, skipping, or rerunning of a subprocess, or process termination—as soon as certain conditions are met. However, it does not support controlling policies according to the dynamic behavior of process execution in SOA. Liang et al. proposed a set of customized policy assertions in WS-Policy, called WS-CustomizationPolicy, which do not provide for the management of dynamic properties [23]. WS-Policy can only specify static properties, and hence it is implicit that these properties will never change when the service is defined. Several proposals had been published to support dynamic policies in Web services. Yee and Korba proposed a flexible security personalization approach that allows the Web-service provider and customer to derive the desired security policy via negotiation [24]. They also discussed how to extend the proposed approach to WS-Policy. Mathes et al. proposed WS-TemporalPolicy, which allows the service developer to attach a validity period to the properties described in WS-Policy [25]. Hollunder proposed a new WS-Policy operator, the if-operator, to enable conditional assertions [26]. This operator can choose assertions dynamically according to the value of a service parameter, the response time, or the cost of services. Baresi et al. proposed the Web-service constraint language (WS-CoL), which specifies user requirements for the execution of certain Web services. WS-attachment and WS-Policy are extended so that applying a policy can be constrained by the WS-CoL expression [27]. The original syntax and semantics.

(22) 13. of WS-Policy have also been extended by others [25, 26, 27], but the disadvantage that the standard Web-services engine is unable to carry out the new policy or assertion remains. Our work avoids this limitation by not needing to extend WS-Policy; instead, we employ the standard Web-services engine and the BPEL engine to support dynamic policies according to DPSL documents in the BPEL run-time system.. 2-3. The DPSL To separate the implementation of the BPEL and the setting of its security policy, Web services, the BPEL, WS-Security, and WS-SecurityPolicy are standalone standards. Web services and the BPEL are proposed first, followed by the corresponding standards for their security such as WS-Security and WS-SecurityPolicy. Since Web services and the BPEL can operate without considering security requirements, WS-Security and WS-SecurityPolicy cannot interfere with the operation of Web services and the BPEL. Thus, the application designer always first defines the Web services and the BPEL required for the application, and then tests the semantics of the defined application without adding the security mechanism. Finally, after the semantics is tested, the designer defines general security policy assertions and applies Web-Services. security,. including. SOAP. Message. security,. WS-Trust,. and. WS-SecureConversation. WS-SecurityPolicy can define only a static security policy, and hence the most flexible way to include multiple security policies in WS-SecurityPolicy is to specify them as possible alternatives [17]. The client can then choose one of these policies to make a particular Web-service transaction. It is obvious that statically providing policy alternatives is not sufficient to implement the motivating examples presented in Section 2-1, since in a real application the security policy may depend on the dynamic behavior of the BPEL execution. In the first.

(23) 14. motivating example, the security requirement depends on the category of the item obtained in activity A1, which is represented as a variable in the BPEL process. In the second example, the security policy changes according to the result of branching in activity D1. Our goal is to separate the BPEL process implementation and security policy, which means that the system designer should not need to change the implementation of BPEL processes when the security policy is altered. Here we consider an SOA application to be a software system consisting of multiple BPEL processes and standalone Web services. Also, we define the dynamic behavior of a workflow process like the BPEL to be the dynamic state under actual operating conditions that is described by various parameters, including variables, the execution history, and the control flow. To synchronize the enforcement of security policies with the dynamic behaviors of an SOA system, the system designer has to embed detectors of the dynamic behavior into the workflow system of an SOA application. The detectors recognize specified behaviors and then instruct the workflow system to perform appropriate tasks to implement certain security policies. Thus, the semantics of the security requirement is closely related to the implementation of the SOA application, and so changing the security requirement always requires the implementation of the SOA application to be modified. This makes the maintenance both difficult and expensive, and so it would be preferable to separate the implementation of the SOA application and the security requirement. Furthermore, an SOA application usually contains multiple workflow systems. For example, the BPEL is designed to implement an SOA application with multiple processes, and the security requirement in one BPEL process may depend on the dynamic behavior of another BPEL process. In this case the dynamic behavior of one BPEL process needs to be detected by another BPEL process..

(24) 15. BPEL0 , BPEL1, …,BPELN-1. A DPSL document D. WSDL0 , WSDL1, …,WSDLN-1. A BPEL-based SOA application without security consideration A BPEL-based SOA application with dynamic security policy. Figure 2-5. An SOA application with dynamic policies In this chapter we propose the concept of dynamic policies, where the enforcement of service policies can depend on the dynamic behavior of the workflow systems in the SOA application. Although here we only discuss how to implement this concept in the BPEL-based SOA architecture, it can be applied in any SOA system. A BPEL-based SOA application initially consists of some BPELs and their corresponding WSDLs (note that a standalone Web service is considered to be a BPEL process that only receives requests and replays the execution result). Referring to Figure 2-5, BPELi and WSDLi, 0i<N, consist of an SOA application without considering security requirements. During software development we usually first design an application without a security policy requirement. After its functionality is tested, we then attempt to add the security policy requirement to the application. We need to consider how to define the security policy requirement in the DPSL. Before we provide the details of the DPSL syntax, we first present the general syntactic form of a DPSL document (Figure 2-6). A DPSL document, which is defined as being an XML document, consists of the following three sections:.

(25) 16. Namespaces Declaration. WS-Policy Description (Policy 1 - n). Designated portType name Dynamic behavior descriptor and corresponding WS-Policy link. Dynamic behavior descriptor and corresponding WS-Policy link. Dynamic policy specifier. Figure 2-6. The architecture of a DPSL document 1.. The header section. Since a DPSL document is also an XML document, a DPSL document should begin with an XML declaration that specifies the version of XML being used (e.g., <?xml version="1.0"?>). This section also contains required namespace declarations.. 2.. The WS-Policy description section. This section defines certain policies according to WS-Policy defined by the W3C. These policies are set to be activated dynamically.. 3.. The dynamic policy specifier section. This section contains many dynamic policy specifiers, each of which has a designated portType name that is the portType name in the original SOA application. According to the WS-Policy attachment [20], we can associate a policy to a binding, a portType, an operation, or even an input/output message of an operation. Note that the original SOA application does not specify a WS-Policy. Without loss of generality, we can refer to the portType to specify the dynamic policies since it is the most important WSDL element describing a Web service, the operations that can be performed, and the messages that are involved. Each.

(26) 17. dynamic policy specification can be defined so as to apply different policies under different dynamic behaviors. A dynamic behavior descriptor corresponds to a WS-Policy link that points to a WS-Policy—it describes how to select a WS-Policy in the designated portType. A dynamic behavior descriptor contains a Boolean predi7cate. When it is True, the corresponding WS-Policy will be applied in the designated portType. Since we can only choose one out of multiple WS-Policies in the WS-Policy description section for a portType, the preceding WS-Policy has a higher priority. We can define the scope within which the specified WS-Policies will be applied in the <scope> element. If this element is absent, then the specified WS-Policies will be applied to all the operations contained in the designated portType; otherwise these WS-Policies are only applied to the listed operations or messages. Dynamic policy specifier <Designated_portType name="portType Link"> [<Scope> Elements </Scope>] <Dynamic_behavior_descriptors> Dynamic behavior descriptor { Dynamic behavior descriptor } </Dynamic_behavior_descriptors> </Designated_portType> Dynamic behavior descriptor  <Dynamic_behavior name="Dynamic behavior name" policyURI="policyURI link" > <Position when="before | after"> [BPEL process name:] BPEL activity name </Position> <Inspector> Inspector predicate </Inspector> </Dynamic_behavior> Elements  Element {Element } Element  <Element type="(operation | in | out)"> Operation or Message name </Element> portType Link  String ; Dynamic behavior name  String ; policyURI link  String.

(27) 18 BPEL process name  String ; BPEL activity name  String ; Inspector predicate  String Operation or Message name  String *. String represents a character string.. Figure 2-7. The syntax of the dynamic policy specifier Figure 2-7 shows the syntax of a dynamic policy specifier. We specify syntax definitions in the Backus-Naur Form [28] in this chapter. The XML element <Designated_portType> is the root node of the specifier and the attribute name=“portType Link” is used to point to the portType name in the original SOA application. The dynamic selection of security policy will be applied in this portType. Each Dynamic behavior descriptor element specifies a security policy selection in which the policy specified in policyURI link will be applied when the evaluation of Inspector predicate is True in the execution point noted in element <Position>. The execution point is labeled according to the names of the BPEL process and activity. When the execution of the process reaches the execution point, the Boolean predicate will be evaluated by the run-time system before or after the execution of an activity according the value of the when attribute. We now define the following expressions and functions that are used in the Inspector predicate to verify the dynamic behavior of the BPEL processes:  [BPEL process name:]BPEL variable Xpath. This expression represents the current value of a BPEL variable. BPEL process name and BPEL variable Xpath are the names of the BPEL process and the Xpath that points to the variable, respectively.  CheckFlow.ActivityExecuted([BPEL process name:]BPEL activity name). This Boolean function checks if an activity has been executed. The parameter [BPEL process name:]BPEL activity name is the name of a BPEL activity.  CheckFlow.ActivityExecutedTimes([BPEL process name:]BPEL activity.

(28) 19. name). This function checks the number of times that an activity is executed, and returns an integer.  CheckFlow.BranchResult([BPEL process name:]BPEL activity name). This function checks the result of branching in a structure activity in BPEL, and returns a set of activities that are executed after a structure activity named [BPEL process name:]BPEL activity name. These functions and the expressions defined in XML Path Language (XPath) 2.0 can be used to construct an Inspector predicate. XPath 2.0 allows the use of “and” and “or” in logical expressions. The value-comparison operators are “eq”, “ne”, “lt”, “le”, “gt”, and “ge”. For example, the statement “($VariableName.parameters/V1 ≥ 100) && (CheckFlow.BranchResult(BPEL:D1) &eq; BPEL:I2)” checks if the value of a BPEL variable “Variable_V1” is greater than or equal to 100 and if the result of branching in structure activity “BPEL:D1” is “BPEL:I2”. Figure 2-8A and Figure 2-8B show two DPSL documents for the motivating examples presented in Section 2-1. Figure 2-8A defines the dynamic security policy requirement of our first motivating example. The requirement is that there are two different security policies that should be selected according to the category of the item obtained in activity A1 in Figure 2-1. Referring to Figure 2-8A, lines 7 to 12 define two security policies SP1 and SP1. The dynamic policy specifier of the designated portType “Inve:Inventory-1_Original_PT” at lines 13 to 32 contains two dynamic behavior descriptors. The first descriptor defines. that. if. the. value. of. the. BPEL. variable. “Moti:$BPEL-1_OPRequest.parameters/item_NO” is less than or equal to 100, the policy SP1 should be applied in the designated portType. Similarly, another descriptor defines that if its value is greater than 100, the policy SP1 should be applied. Fig. 8B shows the security requirement of our second motivating example shown in Figure 2-3..

(29) 20. The requirement is that the security policy changes according to the result of branching in activity D1. Similar to Figure 2-8A, lines 7 to line12 in Figure 2-8B define two security policies SP2 and SP2. The dynamic policy specifier of the designated portType “Reg:Register-2_Original_PT” at lines 13 to 32 contains two dynamic behavior descriptors. The first descriptor defines that if the branch result of the BPEL activity “Moti:D1_If” is the BPEL activity “Moti:A2_Invoke”, the policy SP2 should be applied in the designated portType. The other descriptor defines that if the branch result is the BPEL activity “Moti:A3_Invoke”, the policy SP2 should be applied. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33. <DynamicSecurityPolicy name="NCName" targetNamespace="anyURI" xmlns:Inve="http://www.example.org/Inventory-1_Original/" xmlns:Moti="http://Motivation-1_Original" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns="anyURI"> <wsp:Policy wsu:Id=="SP1'"> ... </wsp:Policy> <wsp:Policy wsu:Id="SP1""> ... </wsp:Policy> <Designated_portType name="Inve:Inventory-1_Original_PT"> <Dynamic_behavior_descriptors> <Dynamic_behavior name="Value<=10" policyURI="#SP1'"> <Position when="before"> Moti:A2_Invoke </Position> <Inspector> Moti:$BPEL-1_OPRequest.parameters/item_NO ≤ 100 </Inspector> </Dynamic_behavior> <Dynamic_behavior name="Value>10" policyURI="#SP1"" > <Position when=”before”> Moti:A2_Invoke </Position> <Inspector> Moti:$BPEL-1_OPRequest.parameters/item_NO > 100 </Inspector> </Dynamic_behavior> </Dynamic_behavior_descriptors> </Designated_portType > </DynamicSecurityPolicy>. (A).

(30) 21. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33. <DynamicSecurityPolicy name="NCName" targetNamespace="anyURI" xmlns:Reg=”http://www.example.org/Register-2_Original/” xmlns:Moti=”http://Motivation-2_Original” xmlns:wsp=”http://www.w3.org/ns/ws-policy” xmlns="URI"> <wsp:Policy wsu:Id="SP2'"> ... </wsp:Policy> <wsp:Policy wsu:Id="SP2""> ... </wsp:Policy> <Designated_portType name="Reg:Register-2_Original_PT"> <Dynamic_behavior_descriptors> <Dynamic_Behavior name="Branch=A2" policyURI="#SP2'" > <Position when="before"> Moti:A4_Invoke </Position> <Inspector> CheckFlow.BranchResult (Moti:D1_If) &eq; Moti:A2_Invoke </Inspector> </Dynamic_Behavior> <Dynamic_Behavior name="Branch=A3" policyURI="#SP2"" > <Position when="before"> Moti:A4_Invoke </Position> <Inspector> CheckFlow.BranchResult(Moti:D1_If) &eq; Moti:A3_Invoke </Inspector> </Dynamic_Behavior> </Dynamic_behavior_descriptors> </Designated_portType > </DynamicSecurityPolicy>. (B) Figure 2-8. The DPSL documents for the first (A) and second (B) motivating examples. 2-4. Architecture to support the DPSL in the BPEL run-time system Unlike WS-Security and WS-SecurityPolicy, the DPSL is not an accepted standard, and the existing run-time system of the BPEL cannot support the programming model shown in Figure 2-5 to specify SOA application and dynamic.

(31) 22. policies. We therefore need to modify or enhance the existing run-time system of the BPEL. The first and direct solution is to modify or design a new BPEL engine so that it can parse the DPSL and then communicate with other BPEL engines or Web-services servers according to the dynamic policies defined in DPSL documents. However, since implementing or modifying a BPEL engine is expensive, we design an architecture to support the DPSL in the BPEL run-time system. A major advantage is that it complies with the existing BPEL engine that follows W3C standards. Referring to Figure 2-9, we assume that BPELi and WSDLi, 0i<N, consist of an SOA application without considering security requirements, and D is a DPSL document that specifies the dynamic policies for this SOA application. A DPSL translator reads the security requirements in D and then translates the original SOA application, BPELi and WSDLi, into a new SOA application, BPELi and WSDLi, 0i<N. Note that this new application also complies with the W3C standards, and hence we can use the existing BPEL engine (which is compatible with W3C standards) to execute the new application. Therefore, using the DPSL translator removes the need to implement a new BPEL engine. A DPSL document D. BPEL0 , BPEL1, ,BPELN-1. WSDL0 , WSDL1, ,WSDLN-1. BPEL0 , BPEL1, ,BPELN-1 DSPL translator for BPEL WSDL0 , WSDL1, ,WSDLN-1. Translated BPEL-based SOA application A BPEL-based SOA application without security consideration. Figure 2-9. The operation of the DPSL translator for the BPEL Algorithm 2-1 in Figure 2-10 shows how the DPSL translator generates BPEL processes that implement the dynamic policies specified by a DPSL document.. In.

(32) 23. Step (1), we copy the original BPEL and WDSL documents. BPELi and WSDLi, 0i<N, are identical to the original application. In Steps (2) and (3), we parse the DPSL document D and extract all the dynamic behavior descriptors and store them in a set Z. Step (4) is to install BPEL activities in the original application to evaluate inspector predicates in Z. Note that the result of evaluation of each inspector predicate is stored in a newly created BPEL variable with an unique name. In Step (5) we make translation for all the dynamic policy specifiers separately. For each dynamic policy specifier, we first install some WS-policies in receiving BPEL process by adding some bindings and ports. In the sending process, we have to install some “if condition” and “assign” activities which are responsible to assign an appropriate endpoint reference to its partnerLink so that it can use the appropriate policy. Algorithm 2-1: DPSL transformation for BPEL processes Input: The original SOA documents: BPELi and WSDLi, 0i<N–1, and a DPSL document D. Output: The transformed documents: BPELi and WSDLi, 0i<N–1. (1) Let BPELi=BPELi and WSDLi=WSDLi, 0i<N–1. (2) Parse D. Assume that there are k dynamic policy specifiers dps0, dps1,, dpsk–1 in D..  Let dpsi.(designated portType name) be the specified portType in the dynamic policy specifier dpsi..  Let dpsi.(set of dynamic behavior descriptors) be the set of dynamic behavior descriptors defined in dpsi. If x  dpsi.(set. of dynamic behavior descriptors),. then x.(position), x.(inspector. predicate),. and. x.(WS-Policy) are the defined position, inspector predicate, and corresponding WS-Policy in dynamic behavior descriptor x, respectively. (3) Let Z be the set of all defined dynamic behavior descriptors in D; that is, Z= dps0.(set of dynamic behavior descriptors).  dps1.(set. of dynamic behavior descriptors).    dpsk.(set. of dynamic behavior. descriptors).. (4) FOR each d in Z.  According to d.(position), insert a new activity “before” or “after” the position at BPELi to evaluate d.(inspector predicate). Note that the result of the evaluation is stored in a variable with a unique name that, for convenience, is denoted as $Result_d.(inspector predicate). END FOR (5) FOR j = 0 to k–1.  Let  be the “invoke” activity whose partnerLink is linked to the portType defined in.

(33) 24 dpsj. Assume that  is an activity of BPELx..  Let R = dpsj.(set of dynamic behavior descriptors). Assume that there are m dynamic behavior descriptors in R. Assume that R={r0, r1, …, rm–1}.. . Add m new bindings and m new ports to receiving process BPELy..  Bindingi which is within the porti, 0im–1, is a binding in the WSDL that associates the WS policy specified in ri by policyURI_link; that is, ri.(WS-Policy). Note that all these bindings are associated with the same portType according to dpsj..  Porti, 0im–1, is a port whose address is an unique endpoint reference and is associated to Bindingi..  Insert one “if” activity that contains m “if conditions” and m “assign” activities before  in BPELx, as shown in Figure 2-11..  Bi is a structured activity (i.e., and “if” activity) that checks if $Result_ri.(inspector predicate),. 0im–1, is True or False..  Ii, 0im–1, is an “if condition” that checks the result of the associated inspector predicate of ri..  ai, 0im–1, is an “assign” activity that assigns a endpoint reference to the partnerLink of . The binding of the endpoint reference is associated with the security policy defined by ri.(WS-Policy). END FOR. Figure 2-10. The algorithm which performs the DPSL transformation.  Position. . binding. portType. Receive. . . BPELy WSDLy. BPELx. : partnerLink. WSDLx The original SOA Application. : partnerLinkType.

(34) 25. . . : partnerLink : partnerLinkType. B0. I0. False. I1. True. a0. Im-1. binding0 r0.(WS-Polocy). a1. binding1. am-1 else. r1.(WS-Polocy). .... binding2. portType. Receive. . r2.(WS-Polocy). .... ....  . bindingm-1 BPELy. rm-1.(WS-Polocy. BPELx WSDLx. WSDLy The translated SOA application for Algorithm 1. Figure 2-11. The original and translated BPEL for the example in Algorithm 2-1 The architecture of the translated BPEL programs of the two motivating examples is shown in Figure 2-12 and Figure 2-13 according to the DPSL documents shown in Figure 2-8A and Figure 2-8B. The real BPEL codes are available at http://www.csie.ntnu.edu.tw/~ghhwang/DPSL/DPSL_Motivating_Examples.rar.. Client. binding SP3. A1 B0. I0. True. else. a0 a1. A2. A3 : partnerLink. Inventory Service binding1 SP1’ portType binding2 SP1’’. Register Service binding portType SP2. A4. : partnerLinkType. BPEL. WSDL The translated BPEL for the first motivating example.. Figure 2-12. The translated BPEL for the first motivating example.

(35) 26. Client. binding Policy. A1 D1. If else. True. A2. Inventory Service 2 binding portType Policy. A3. B0. I0 else. True. a0. a1. : partnerLink : partnerLinkType. A4. WSDL. BPEL. Inventory Service 1 binding portType Policy. Register Service binding1 SP2’ portType binding2 SP2’’. A5. The translated BPEL for the second motivating example.. Figure 2-13. The translated BPEL for the second motivated example. 2-5. Implementation and experiments We constructed a simple implementation of the DPSL translator that omitted some of the functions mentioned above (e.g., the scope). The implementation was translated into the two motivating examples presented in section 2-1. The software packages used to conduct our experiments included Apache AXIS2 1.5.1 [29], Apache AXIS2 Module: SOAP Monitor [30], JDK 1.5.0_21, Eclipse WTP [31] with soapUI plug-in [32], and ActiveBPEL Designer [33]. For the original BPEL document, we first employed Eclipse WTP to edit the WSDL documents, and then used the Apache AXIS2 Code Generator to generate the Java code template from the WSDL, with this template being used to design the operation codes. Finally, the service was deployed on the AXIS2 engine. The BPEL document was constructed using ActiveBPEL Designer and deployed to an ActiveBPEL engine to test its functionality. We employed the DPSL translator to generate the BPEL and WSDL documents. Table 2-1 and Table 2-2 list the numbers of lines of the original and translated BPEL and WSDL documents for the two motivating examples. The translated codes were deployed to the AXIS2 and ActiveBPEL engines to verify their correctness. The.

(36) 27. translated codes were significantly larger, which is due to them containing additional codes to activate the dynamic policies defined in the DPSL. Compare the original codes with translated codes, there is a thirty percent increase in the code sizes on average. In the two examples, there is only one dynamic policy specifier in the DPSL document. There will be more increase in the code sizes if there are more dynamic policy specifiers in DPSL documents. Table 2-1: Code sizes of the Motivation-1 WSDL and BPEL documents Before translation. After translation. Motivation-1_Original.bpel. 84 lines. 115 lines. Inventory-1_Original.wsdl. 55 lines. 70 lines. BPEL-1_Original.wsdl. 63 lines. 63 lines. Table 2-2: Code sizes of the Motivation-2 WSDL and BPEL documents Before translation After translation Motivation-2_Original.bpel. 126 lines. 174 lines. Register-2_Original.wsdl. 55 lines. 70 lines. BPEL-2_Original.wsdl. 68 lines. 68 lines. In the second part of our experiments, we conduct experiments to evaluate the execution time of the original and translated BPEL processes. To evaluate the overhead of the translated BPEL processes, we arrange the BPEL processes and invoked services in the same machine. Since translated BPEL processes need to add some “if” and “assign” activities, it needs more time to finish the execution. Referring to Table 2-3. The original BPEL process of Motivation-1 needs about 148 ms to finish the execution which contains invocation of two Web services. The translated BPEL processes need about 156 ms to finish. The overhead is generated because the extra execution of added “if” and “assign” activities. However, if we translate the code manually, it also has to add some “if” and “assign” activities because the security.

(37) 28. policies should be changed according the dynamic behavior of the BPEL processes.. Table 2-3: Execution time of the original and translated BPEL processes of Motivation-1 and Motivation-2 Motivation-1 BPEL process Motivation-2 BPEL process. Before translation. After translation. 148 ms. 156 ms. 151 ms. 163 ms.

(38) Chapter 3. Transient Policy to Support Dynamic Access Control in Service-Oriented Architectures and Workflow Management Systems A service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed services that may be under the control of different ownership domains [34]. 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. An SOA requires the services to be only loosely coupled to the operating system and other technologies that underlie applications, and it separates functions into distinct units, or services [35], that developers make accessible over a network so that users can combine and reuse them when producing applications. An SOA can be implemented in a software framework such as Web services [35]. Web services make functional building blocks accessible over standard Internet protocols independently of the types of platforms and programming languages. These services can be new applications or legacy systems wrapped to make them network-enabled. One of the goals of an SOA is to allow users to combine various functions to form ad-hoc applications that are almost entirely developed from existing software services. Orchestration is normally required to produce a new application [36]. A high-level language such as the Business Process Execution Language (BPEL) extends the service concept by providing a method for defining and supporting the orchestration of fine-grained services into coarser business services [37]. Orchestration involves ensuring that Web services interact with each other at the message level, including the business logic and execution order of the interactions from the perspective and under the control of a single endpoint. This involves an executable 29.

(39) 30. business process that may result in a long-lived, transactional, multistep process model. In fact, the BPEL incorporates a workflow model to describe the orchestration of Web services. An SOA is therefore a useful technical platform for workflow software. 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 (ACM), where an access request from a subject can be granted if the requested access right is recorded in the matrix [38]. A similar access control model is the access control list (ACL), which is usually related to a computer file system and is a list of permissions attached to a file or object [39]. 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 [40]. The RBAC model is regarded as a neutral policy and has been the most popular security model in recent years. In this model 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 system functions. RBAC assumes that the permissions needed to perform an organization’s roles change slowly over time, but that users may enter, leave, and change roles rapidly. A pure RBAC solution may provide inadequate support for dynamic attributes such as the time of day, which might need to be considered when determining user permissions. Supporting access control (particularly in large organizations) can result in a “role explosion” due to thousands of separate roles being created for different collections of permissions. Although RBAC provides a solid foundation for managing information security, administrators may be burdened with.

(40) 31. having to maintain hundreds or even thousands of roles across several applications. The number of roles increases with the number of connected systems, and an organization with a thousand employees can easily end up with several thousand roles [41]. Such role explosion usually occurs in information management systems controlling access in dynamic and heterogeneous infrastructures with combinations of employee turnover and security policy. Recent work in attribute-based access control (ABAC) [42] 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 which can dynamically adjust role assignments and permission assignments based on context information [43]. The central idea of ABAC is that access can be determined based on various attributes presented by a subject and by attributes of the environment, such as an employee only being allowed to access certain data during his/her working hours. Figure 3-1 shows the operation of ABAC. The administrative domain2 maintains a set of long-term policies3 that are stored in a policy pool (these policies are said to be “long term” since they do not change rapidly). The ABAC can support dynamic roles4 in which attributes such as the time of day are used by a front-end module to determine the subject’s role, retaining a conventional role structure but changing role sets dynamically. Note that roles are not created when a request is made; instead, a subject is bound to a role according to some access rules when a request is granted. While ABAC may require up to 2n access rules for n attributes, attempting to implement the same controls in RBAC could in the worst case require 2n roles [44]. A request RQ of a subject to an object takes the form RQ=(S, O, R), where S is the 2 An administrative domain is a service provider with access to a security repository, which makes it easy to authenticate and authorize clients with credentials. 3 In this paper we use the terms “policy” and “access control policy” interchangeably. 4 There are various ways to specify and implement dynamic roles; see Section 3-6..

(41) 32. subject, O is an object, and R is the set of operations that S is going to perform on O. In the worst case, determining the permissions available to a particular request will require evaluation of all of the long-term policies, which potentially contain a large set of access rules in the policy pool. Dynamic attributes collection. Policy pool Maintain (Insert, delete, …). Administrative domain. Long-term policies. Access request (S,O,R). Resource manager. Resource Resource Resources. Figure 3-1. Operation of ABAC Standards related to an SOA such as Web services and BPEL do not support the specification of either authorization policies or authorization constraints on the execution of activities constituting a business process. The increasing popularity of SOA services makes it necessary to consider how to support access control, since services may have to access data objects maintained by other servers [45, 46]. 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 [47]. The XACML is an access control model that incorporates the RBAC model, and it was designed to work in conjunction with the Security Assertion Markup Language [48]. Since the XACML is based on RBAC, it only considers the static binding between subjects, objects, and roles; that is, the access control policy cannot be regulated according to the dynamic behaviors of the SOA system. The dynamic behaviors in an SOA-based application are related to run-time states.

(42) 33. and histories, including variables of workflow processes and flow control results and histories. It is necessary to investigate if statically specifying the access control fulfills the requirements of the workflow-based SOA environment. In this chapter we first present a motivating example to demonstrate that access control is usually influenced by dynamic behaviors in a workflow-based system. We then propose a novel access control model called workflow-based dynamic access control (WBDAC) in which the access control system can create transient policies according to the reference environment of the workflow process. The lifetime of a transient policy is equal to or shorter than the lifetime of its corresponding workflow process: so, the proposed model can alleviate the role- and rule-explosion problems in traditional or extended versions of RBAC and ABAC for workflow applications. To implement the WBDAC, we define the dynamic access control language for an SOA (DACL4SOA), which is a logical expression of the WBDAC. Although the DACL4SOA is designed to cooperate with previously proposed standards, such as the Web Services Description Language (WSDL), BPEL, and XACML, we believe that the method of incorporating dynamic access control using the DACL4SOA can be applied to any SOA framework. We also show that if the access control in a workflow-based SOA system cannot be specified according to dynamic behaviors of workflow processes, then the resulting overly tight coupling between the access control requirements and the flow structure will increase the difficulty, overhead, and cost of system development and maintenance. According to the separation-of-concerns principle, implemented Web services should only provide the required core functionality. The WBDAC can separate the specification of the access control requirements and service orchestration so as to reduce the software development and maintenance cost of an SOA system. The implementation and experimental results presented herein demonstrate the feasibility of the proposed.

雲端環境中為服務導向架構支援安全性， 可信任及協同合作

雲端環境中為服務導向架構支援安全性，可信任及協同合作