THÈSE. l ÉCOLE NATIONALE SUPÉRIEURE DES TÉLÉCOMMUNICATIONS DE BRETAGNE. DOCTEUR de Télécom Bretagne. Samiha AYED

Transcription

1 N d ordre : 2009telb0109 THÈSE Présentée à l ÉCOLE NATIONALE SUPÉRIEURE DES TÉLÉCOMMUNICATIONS DE BRETAGNE en habilitation conjointe avec l Université de Rennes 1 pour obtenir le grade de DOCTEUR de Télécom Bretagne Mention «Informatique» par Samiha AYED SECURE WORKFLOW DEPLOYMENT IN MULTI-ORGANIZATIONAL ENVIRONMENTS À soutenir le 09 Novembre 2009 devant la Commission d examen : Composition du Jury - Rapporteurs : Lionel BRUNIE, Professeur, INSA de Lyon, France Yamine AIT AMEUR, Professeur, ENSMA Poitiers Futuroscope, France - Examinateurs : Pascale SEBILLOT, Professeur, IRISA / INSA de Rennes, France Marc FRAPPIER, Professeur, Université de Sherbrooke, Québec, Canada - Encadrants : Nora CUPPENS-BOULAHIA, Enseignant-chercheur, Télécom Bretagne, France Frédéric CUPPENS, Professeur, Télécom Bretagne, France

2

3 Abstract WFMS (Workflow Management Systems) are systems managing, controlling and supporting processes as workflows. A workflow is a process composed of a set of tasks having to be executed in a specific order by different subjects and roles and using different resources. During the workflow execution, different subjects communicate between each other. The diversity characterizing these systems and different communications that can exist within them lead us to be concerned about their security. In this thesis, we deal with access and flow control within these systems. In literature, many works tried to address this issue, but proposed solutions remain insufficient towards the requirements of these systems. In this thesis, we propose new approaches to manage the security within WFMS. We define an integrated model which takes into account not only the access control but also the information flow control. This integrated model is based on the OrBAC model. The security policy has to take into account different constraints defined with the workflow specification. The execution of the workflow has to not violate the set of workflow constraints otherwise, the functional behavior and the security part of the workflow will be affected. Then, the security policy specification is applied to a Petri net based model to control the execution of the workflow. The definition of our Petri net model is also based on OrBAC concepts. We define a decentralized procedure to execute the workflow. This procedure includes different workflow agents to ensure the security of the workflow. In addition, we study the complexity of the workflow satisfiability problem which consists on searching for an assignment of users to different tasks without violating workflow constraints. Another part of this work deals with the deployment of the security policy. The deployment approach depends on the type of the execution mode of the workflow (centralized or distributed), on the type of the workflow (intra or inter organizational) and on the security approach to be used (outsourcing or provisioning). Finally, we show how we can integrate these security requirements using a web services oriented tool. Key words: WFMS, Security Policy, OrBAC, Petri Nets, Deployment, Access and Flow Controls

4

5 Résumé WFMS (Workflow Management Systems) sont les systèmes qui gèrent, contrôlent et supportent les processus en tant que workflows. Un workflow est un ensemble de tâches qui doivent être exécutées dans un ordre bien determiné par des différents utilisateurs et rôles et en utilisant des différentes ressources. Durant l exécution du workflow, les différents sujets communiquent entre eux. La diversité qui caractérise ces systèmes et les communications qui peuvent avoir lieu au sein du système nous amènent à s intéresser à la sécurité des WFMS. Dans la littérature, plusieurs travaux ont essayé d étudier ce sujet et de donner des solutions qui restent non satisfaisantes aux besoins de ces systèmes. Dans cette thèse, nous proposons des nouvelles approches pour gérer la sécurité au sein des WFMS. Nous définissons un modèle intégré qui prend en compte le contrôle d accès et de flux. Ce modèle intégré est basé sur le modèle OrBAC. La politique de sécurité ainsi définie doit exprimer les différentes contraintes définies avec la spécification du workflow. L exécution du workflow ne doit pas violer l ensemble des contraintes du workflow. Une fois définie, la politique de sécurité est appliquée à un modèle basé sur les réseaux de Petri modélisant le workflow. La définition de notre modèle de réseaux de Petri est basé sur les concepts OrBAC. Aussi, nous définissons, une procédure décentralisée pour l exécution du workflow. Cette procédure inclut tous les agents du workflow pour assurer la sécurité du workflow. En plus, nous étudions la complexité du problème de satisfiabilité du workflow qui consiste à chercher une affectation possible des différents utilisateurs aux différentes tâches sans avoir violé l ensemble des contraintes. Une autre partie de ce travail concerne le déploiement de la politique de sécurité. Notre approche de déploiement dépend du mode d exécution du workflow (centralisé ou distribué), du type du workflow (intra ou inter organisationnel) et de l approche de sécurité à appliquer (outsourcing ou provisioning). Finalement nous montrons comment nous intégrons ces aspects de sécurité en utilisant un outil orienté web service. Mots clés: WFMS, Politique de sécurité, OrBAC, Réseaux de Petri, Déploiement, Contrôle d accès et de flux

6

7 Contents Abstract Résumé Contents List of Figures List of Tables i iii v ix xi 1 Introduction Context of this thesis Objectives and Contributions Outline of the Dissertation Preliminaries and related works Introduction Workflow Management Systems Service Oriented Architecture and Web services New Requirements for Security Access Control Models TBAC: Task Based Access Control model RBAC: Role Based Access Control model TMAC: TeaM based Access Control model OrBAC: Organizational Based Access Control model Information Flow Control Models Multi Level Security models: Bell-LaPadula model DTE: Domain Type Enforcement Related Works Workflows Security Based on Onion Encryption Techniques Specifying Access and Flow Control Within WFMS

8 vi CONTENTS Access Control Flow Control Discussion Collaborative Environments: VO management Conclusion An integrated model for access control and information flow requirements Introduction Motivation DTE principles DDT and DIT tables Domain transition problem and entry point notion An example of DTE policy Towards a DTE Formalism Generalities Confidence Path Concept DTE Rules Access and information flow control convergence Access control policy Information flow control policy Example Conclusion Modeling WFMS and Specifying WFMS Security Policy Introduction Generalities About Petri Nets WFMS Constraints Classification and Consistency Static constraints Dynamic constraints Constraints consistency Modeling WFMS WFMS Petri Net Model Example Specifying WFMS global security policy Access Control Policy WFMS General Security Policy WFMS Coordination Security Policy Information Flow Control Security Policy Secure Environment to Workflow Execution

9 CONTENTS vii Decentralized Control Algorithm to Deploy WFMS Security Requirements Example Complexity of the Workflow Satisfiability Problem Problem statement Problem statement Problem statement Discussion Conclusion Deploying security policy in intra and inter WFMS Introduction Functional approaches of WFMS Centralized and distributed workflows Intra and inter organizational workflows WFMS Security policy management Outsourcing approach Provisioning approach Deploying WFMS security policy Intra-organizational case Specification environment Enactment environment Inter-organizational case Creation of VO VO security policy Inter-organizational deployment Case study: telesurgery Conclusion Implementation Introduction Workflow orchestration Existing tools Intalio designer Intalio Workflow Tempo MotOrBAC and OrBAC API Integration approach Secured workflows Integrating OrBAC policy to secure workflow execution Extending OrBAC contexts

10 viii CONTENTS 6.6 Discussion Conclusion Conclusion & Perspectives Concluding remarks Discussion Perspectives A Résumé 153 A.1 Introduction A.2 Preliminaires et travaux réalisés A.2.1 WFMS et le contrôle d accès A.2.2 WFMS et le contrôle de flux A.2.3 Etude de l existent A.3 Un modèle intégré pour le contrôle d accés et le contôle de flux A.3.1 La notion de Entry Point A.3.2 Expression de la politique de sécurité A.4 Modélisation des WFMS et spécification de sa politique de sécurité. 162 A.4.1 Modélisation des workflows basée sur les RdP A.4.2 Spécification de la politique de sécurité A.4.3 Environnement sécurisé pour l exécution distribuée du workflow165 A.4.4 Complexité du problème de satisfiabilité du workflow A.5 Déploiement de la politique de sécurité A.5.1 Différents modes d exécution et types des workflows A.5.2 Approches de gestion de politiques de sécurité A.5.3 Déploiement de la politique de sécurité A Le cas intra-organisationnel A Le cas inter-organisationnel A.6 Implémentation A.7 Conclusion Bibliography 173

11 List of Figures 1.1 Global framework of the thesis Workflow phases Workflow example Service Oriented architecture concepts and technologies TBAC: an active access control model RBAC model TMAC illustration OrBAC model The hierarchical security levels WfRM reference model Virtual Organization Principle The problem of domain transitions Sample DTE policy file Sample of a graphic system topology Example of a Petri net Petri net marking Workflow of the travel application Modeling for the travel application Modeling for the SPN Modeling for the SPN Modeling for the SPN Applying access and flow control on a Petri net Set of task predicates Petri net banking application Initial graph of the = relation Reduction of the = relation graph Centralized and distributed workflow

12 x LIST OF FIGURES 5.2 Inter-organizational workflow Outsourcing in a centralized and a distributed workflow Provisioning in a centralized and a distributed workflow Security policy deployment using a provisioning approach A simple workflow of a telesurgery operation BPMN Palette Intalio user interface User role assignment Global Tempo architecture General Tempo diagram MotOrBAC architecture Complete Architecture Security communication diagram Contexts implementation Ensuring information flow control A.1 Le modèle OrBAC A.2 Application du contrôle d accès et de flux sur le réseau de Petri A.3 L approche outsourcing dans un workflow centralisé et distribué A.4 L approche provisioning dans un workflow centralisé et distribué A.5 Déploiment de politique de sécurité en utilisant une approche provisioning A.6 L architecture MotOrBAC A.7 Architecture globale

13 List of Tables 3.1 DTE policy corresponding to the system topology DTE and OrBAC concepts correspondence Different temporal constraints between two tasks WFMS coordination security policy Algorithm elements Algorithm input policy Algorithm output policy Orchestration Web services tools Tempo components Petri net based simulation tools A.1 Les différentes contraintes temporelles entre deux tâches A.2 Politique de coordination

14 xii LIST OF TABLES

15 Chapter 1 Introduction 1.1 Context of this thesis Collaborative environments in different domains are always present to achieve a common goal. An eloquent example of these environments are Workflow Management Systems (WFMS). These systems allow organizations to define, manage and control their activities. The whole of these activities constitutes a business process called workflow. Thus, different processes, either automated or not, can generally be modeled as workflows. The procedure of opening a banking account or a demand for a mission are two workflow processes. The definition of these workflows is correlatively defined with specific execution orders and specific conditions. The execution of a workflow has to be done in compliance with the initial workflow specification. The execution of different tasks of a workflow can be shared between many subjects. These subjects can be either human beings or system applications. These subjects or users can be assigned to different roles when executing workflow tasks. When executing these tasks, subjects have to use system or organization resources in order to accomplish different tasks. The execution of the workflow is called instance of the workflow. Besides, these resources can be used by more than one user and can be required for access by different subjects, at the same or different instances of the workflow. Workflow tasks can be conditioned by different conditions and circumstances. These conditions can have different types. They can be either initially defined independently of other workflow tasks or defined depending on the tasks executions. These conditions are considered in the workflow specification as constraints. They can be defined on tasks, on subjects or on roles executing these tasks. To be able to achieve the final goal of the workflow, workflow tasks are interdependant. They have to be executed in a specific order and they can exchange information flows between each other. These communications must respect infor-

16 2 Introduction mation properties especially if data with different sensitivity degrees are exchanged. When executing the workflow, different workflow constraints must not be violated, otherwise, the workflow may not be correctly executed. Thus, we obviously notice that functional aspects of WFMS are characterized by a very large diversity of constraints and requirements. This diversity of tasks, constraints, subjects executing tasks, roles and resources make them very cimokex to manage. Therefore, to achieve the goal of a workflow, controlling the whole workflow execution is necessary. To do so, first of all, we have to be sure that subjects and roles that will execute workflow tasks have really the permission to accomplish these tasks. So, access control is needed. Many access control models have been defined in the literature but they are not all adequate for WFMS. To satisfy different WFMS requirements, it is obvious that we need an efficient model which can be synchronized with the workflow execution. With the dynamic aspect and different changes that can occur during a workflow execution, it is necessary to have a dynamic model to express access control. Within a workflow, we notice that using only an access control model can not ensure a secure workflow execution environment. Since flows are exchanged between different workflow subjects executing tasks, controlling these flows is a critical issue especially when we deal with sensitive information and data. To do so, we have to deal with information flow control into rules controlling access control. This control has to manage different communications between different subjects and roles and it must be synchronized with the execution of the workflow. As a matter of fact, during the workflow execution, a subject can be assigned to more than one role to satisfy workflow constraints. These different assignments have to be supervised in order to not lead to a leakage of data of sensitive data. Thus the security policy associated with the workflow has to be dynamic and it must be dynamically updated with the progress of workflow execution. In fact, if a change occurs during the workflow execution, this change must be taken into account in the security policy. As a matter of fact, it is possible within a workflow that a subject initially assigned to execute a task is not able to execute it after a specific circumstance. After this change, another subject will accomplish this workflow task. This change must be secure and so must be taken into account by the security policy. To satisfy requirements of dynamism of the workflow, its security policy has to be dynamic to take into account different conditions defined with the workflow specification or also different events that can occur during the workflow execution. 1.2 Objectives and Contributions The work done in this thesis contributes to the security of WFMS. Many works have been done around the security of WFMS. Several limitations of these works and the critical need to give security to WFMS are the main initiators of this thesis.

17 1.2 Objectives and Contributions 3 The approach that we follow in this work is based on the definition of security policies that can be adequate to workflow characteristics and satisfy different workflow requirements. Let us summarize the main contributions of this thesis. First of all, after locating different weaknesses in the related works, we merge access and information flow control into a single integrated model. These two controls are essential to be present within WFMS. So, to have a coherent security policy, we define security policy rules based on same concepts either for expressing access control or for expressing information flow control. For this purpose, we will base our security policy on the OrBAC (Organization Based Access Control) model [KBB + 03]. These rules will be enriched using concepts of the DTE (Domain Type Enforcement) model [TP97] in order to take into account information flow control. We will notice that the use of OrBAC model is very useful and efficient within WFMS since it provides high flexibility when defining security rules. Based on this model, security rules may be depend on contextual conditions. This will be used to control the dynamic requirements associated with WFMS execution. Using contextual security rules, different workflow constraints can be expressed and taken into account. Thus, the specification and the security of the workflow will be specified and enforced. We will see that using this approach we can go beyond the static approaches already proposed in the literature. Then using this security policy specification, we define a decentralized procedure which is responsible for supervising the workflow execution and so it ensures a secure environment for the workflow execution. In previous works, a centralized entity is always considered as responsible for controlling functional and security aspects of the workflow. This approach makes this centralized entity a bottleneck since it must have a global vision of the whole workflow execution. All agents executing the workflow do not have any knowledge about what is happening in the workflow. They only know the task that they have to perform. In this thesis we consider a decentralized procedure to execute the workflow which is based on distribution of security controls on all workflow agents involved in the workflow execution. To make workflows more comprehensive and more functional, we use Petri nets as they are an easy and very understandable modeling tool. We define a Petri net based model of workflows. This model takes into account different execution modes of the workflow. Since Petri nets naturally represent parallelism, sequence and concurrency modes, they will be used to define a rich model of workflow execution. This Petri net model will integrate concepts used to specify our security policy. The security policy will supervise the execution of the Petri net modeling the workflow. Another contribution of this thesis concerns the deployment of the security policy once it is defined and specified. Previous works do not deal with this issue. In this thesis we show the whole process from the workflow specification until the accomplishment of the workflow execution in a secure environment. We study different

18 4 Introduction approaches that can be applied through either a centralized workflow or a decentralized workflow. In this later case, we will see how different agents of the workflow participate to ensure the functional and security requirements of the workflow. The deployment approach that we propose is studied either in intra or inter organizational workflows. Obviously, the second case is more complex to manage since it implies many exchanges and information flow between different organizations that must be supervised and secured. The inter-organizational case is exemplified using a telesurgery application. 1.3 Outline of the Dissertation This thesis proposes an integrated framework as presented in figure 1.1 to specify and deploy security in collaborative environments, especially WFMS. To do so, the remainder of this manuscript is outlined as follows. Figure 1.1: Global framework of the thesis Chapter 2: In this chapter, we introduce mainly the basic background of our work and different related works done around the security in WFMS. We start by defining thee systems in section 2.2. In section 2.3 we make a short presentation of web services considered as an eloquent example of WFMS. Section 2.4 defines different security requirements of these systems. We make a synthesis of different access and flow control models that can be relevant within the context of WFMS respectively in section 2.5 and 2.6. We will conclude that the OrBAC model is an adequate model to specify security policies of a workflow. Also, we will notice that multilevel security could not be considered as the best choice to deal with information flow control within these systems. Throughout section 2.7 we go around

19 1.3 Outline of the Dissertation 5 different works done to study security of WFMS. We highlight different limitations and drawbacks of these works. Then, we sketch the approach that we will apply to remedy to these different insufficiencies during this thesis. Chapter 3: In this chapter, we propose a convergence between access and information flow controls to be applied to WFMS. Section 3.2 provides different motivations of this work. Section 3.3 clarifies DTE principles and especially the entry point notion. Section 3.4 defines our DTE formalism. In section 3.5, we introduce and exemplify our integrated model for access and information flow control. Finally, we conclude by summarizing different ideas presented in this chapter in section 3.6. Chapter 4: The chapter presents a model of workflow based on Petri nets and the definition of a secure execution environment for the workflow. It is organized as follows. Section 4.2 introduces basic concepts of Petri nets. Then, section 4.3 presents different constraints that can be specified with the definition of a workflow and their classification. This classification provides means to specify fine-grained execution modes between tasks using Allen s temporal intervals [JAM93]. Section 4.4 defines the Petri net based model that we use to represent workflows. In section 4.5 we introduce the security policy that we associate with the model. This security policy is based on the integrated model presented in chapter 3. It gathers a general security policy and a coordination security policy to define the access control and it deals with information flow control. Section 4.6 addresses the issue of distributed workflow execution and defines an algorithm to generate the local policies required to execute the workflow in a secure distributed way. It also discusses the algorithm with the help of an example. Section 4.7 studies the complexity of the workflow satisfiability problem. It shows that this problem is NP-complete. Finally, section 4.8 discusses our contribution and concludes the chapter. Chapter 5: In this chapter we deal with the deployment of the security policy within either an intra-organizational or an inter-organizational environment. The chapter is organized as follows. Section 5.2 introduces the functional approaches of workflow management systems. So it presents their centralized and distributed modes and their intra and inter organizational types. Section 5.3 introduces provisioning and outsourcing approaches to manage security policy within a workflow. Section 5.4 explains how to deploy the security policy associated with WFMS. It specifies our approach to deploy a security policy either in intra or inter organizational workflow. Section 5.5 illustrates the inter-organizational case through a telesurgery application. Finally, section 6 concludes the chapter.

20 6 Introduction Chapter 6: In this chapter we show how we can integrate security requirements within WFMS and how they can be implemented. To do so, we need a modeling and orchestration tool to be able to represent workflows. This is the topic of section 6.2. In section 6.3, we are interested in the MotOrBAC prototype and the OrBAC API. Using this prototype, the security policy is specified using the OrBAC model as previously explained in chapter 3. Then we show how the OrBAC API can be used to progammatically create OrBAC policies. This API will be integrated into the orchestration tool to control the workflow execution. Thus, the execution environment of the workflow is securely defined according to the defined OrBAC policy. In section 6.6 we show how this integration is done in order to define secure workflows. It is based on two parts. Firstly, changes are made on the SFW (Security FrameWork) specification to base security requirements on a more dynamic model. Secondly, extension of different OrBAC contexts must be done in order to take into account different WFMS constraints that can be defined with the workflow specification. Section 6.7 concludes this chapter. Chapter 7: This last chapter closes the thesis by giving concluding remarks and different perspectives for future investigation.

21 Chapter 2 Preliminaries and related works 2.1 Introduction The security of WFMS is a critical issue as these systems combine a complex diversity of security requirements. Indeed, within these systems many tasks are defined. These tasks have to be executed in a coordinated manner. In order to execute these tasks, many subjects can act and they can have different roles during the workflow execution. To ensure a secure environment of workflow execution we have to be sure that these tasks are executed by authorized subjects. On the one hand, these subjects need accesses to different system resources to achieve different tasks. Thus an access control model is needed. On the other hand, since the tasks of a workflow are inter-dependant, subjects executing these tasks have to communicate with each other. These communications can cause problems especially when we have subjects with different confidence degrees. Therefore an information flow control is needed to ensure secure communication within the workflow. Moreover, the workflow specification defines constraints on the workflow execution. These constraints can have different types, but they must be satisfied during the execution of the workflow in order to preserve the functional definition of the workflow. In this thesis, we are interested in controlling the access and information flow in these systems. In this chapter, we start by defining these systems in section 2.2. In section 2.3 we make a short presentation of web services considered as a significant example of WFMS. Section 2.4 defines different security requirements of these systems. We make a synthesis of different access and flow control models that can be relevant within the context of WFMS respectively in section 2.5 and 2.6. We will conclude that the OrBAC model is an adequate model to specify security policies of a workflow. Additionally, we will observe that multilevel security cannot be considered as the best choice to deal with information flow control within these

22 8 Preliminaries and related works systems. Throughout section 2.7 we go around different works done to study security of WFMS. We highlight different limitations and drawbacks of these works. Then, we show the approach that we will apply to remedy to these different limitations during this thesis. 2.2 Workflow Management Systems A workflow is a representation of a process. It is the automation of business procedures towards reaching a business goal. This process is divided into many tasks having an inter-dependent execution. The execution of these different tasks may include temporal constraints or conditions. Actually, we can can consider different constraints associated with tasks execution: two tasks may be executed in sequential, parallel or concurrent mode. A workflow is composed of two phases: a building phase and an execution phase. These phases are represented in figure 2.1. The first phase defines the formal representation of the process. The second one is an instantiation of the workflow which is based on the specification defined in the first phase. To execute the workflow, communications with users and external applications are often needed. To manage the coordination between the execution of different workflow tasks, we need an entity which ensures the synchronization or that the different agents executing the workflow tasks take the responsibility to ensure it. In typical business processes which rely on a central entity to assure the control of tasks execution, we notice a performance bottleneck which degrades the execution of business collaborations. Figure 2.1: Workflow phases A WFMS [DLTW97] is a system which supports the specification, control, coordination and administration of processes using workflows. This is done through the

23 2.3 Service Oriented Architecture and Web services 9 execution of software which implements the logic of workflows. These systems are used in different domains: research, industry, commerce, etc. Their management can be either centralized or distributed, according to the tasks of the process and the operational mode of the system. These systems may include many subjects or roles and many resources when managing and executing different workflows. This introduces the need to care about the security in these systems. Tasks of a workflow may be executed by the same subject or by different ones having different roles and requiring access to different resources of the system. So, to ensure a secure execution, tasks must be executed by authorized persons or subjects and according to their execution order specification. In addition, subjects must have access only to objects available and authorized. These accesses must be limited to the period of task execution. Thus, granting or revoking privileges must be synchronized with the workflow execution progress. All these requirements lead us to combine the workflow design and the associated security policy. Since security is essential and represents an integrated part of a workflow, this security policy must ensure many properties: integrity, authorization, availability, confidentiality, authentication and separation of duty. Figure 2.2 shows an example of a workflow representing the process of reviewing a paper. The workflow is composed of seven tasks. We start by collecting all the submitted papers. Then, these papers are distributed to different reviewers (3 reviewers in this case). During the execution of these tasks only reviewers have access to the paper. These three activities are executed in a parallel mode. Once these three tasks are executed, we transit to the activity of reviews summarizing. During this task, the decision of accepted or rejected is done depending on the set of reviews. The final task consists in forwarding the decision to the authors. The following constraints represent some of the constraints that the workflow can have: Task 6 (summarize reviews) can not be started before the end of tasks 3, 4 and 5 (Review 1, 2 and 3). Tasks 3, 4 and 5 must be executed by three different subjects (SoD constraint) Subjects executing tasks 3, 4 and 5 can not be the authors of papers being reviewed. 2.3 Service Oriented Architecture and Web services Web services can be considered as an example of workflows. They consist in a set of services provided to leverage their business functionalities. These functionalities are used, integrated or coordinated over the web. The ultimate goal of web services

24 10 Preliminaries and related works Figure 2.2: Workflow example is to offer an interoperable framework. To do so, we do not depend on any specific implementation for business-to-business and business-to-customer interactions. Different interactions between business partners rely on simple standards and protocols including XML [XML], SOAP [SOA] or HTTP. The service oriented architecture is based on a set of concepts. First, a service provider who offers access to some business functionalities. Service providers expose their service interface using the WSDL standard [CCMW01] that is an XML-based language. Second, a client would like to access some business functionalities matching their needs. Third, the service repository which makes the glue between clients and service providers. This repository contains WSDL interfaces and it is generally implemented using the UDDI standard [Ca04]. Service providers can register their business functionalities while clients can browse the repository listings. Once the client has found its appropriate service provider, it can invoke the operations defined by the provider to activate this service. The communication between the client and the service provider is based on the SOAP protocol. Figure 2.3 summarizes these different concepts and exchanges. As we have said, web services are considered as an example of workflows. In this thesis, we do not consider the technologies of web services. We consider an abstraction of these technologies. We are located on a conceptual level where an abstraction is considered. However, solutions proposed in this work to deal with security within WFMS are available to be used and deployed in web services. In fact, we will see that we will be oriented to web services technologies in the implementation part of this work. We will use them to apply the integration of security requirements within a workflow. 2.4 New Requirements for Security The execution of a workflow has many characteristics. But we must not take into account just functional requirements. Indeed, these functional requirements imply new security requirements and we have to take care about them when executing a workflow. The diversity of resources, tasks, subjects and roles executing these

25 2.4 New Requirements for Security 11 Figure 2.3: Service Oriented architecture concepts and technologies tasks lead to worry about the respect of different workflow constraints. To ensure a right execution of the workflow, task executions have to be properly controlled in order to not violate workflow constraints and security requirements of the system. The dynamic aspect of workflows strengthens security requirements. On the one hand, sharing resources and documents between different workflow partners, which can be needed at the same time, imposes enforcing access control policies. On the other hand, the same subject can be assigned to different roles to execute different tasks using different resources. When executing these tasks, this subject will gather information from the system which can be sensitive or not. So, due to the multiple roles that the subject can play, she can access documents or information to which she does not have permission. To solve such a problem information flow control models are needed. Thus, the workflow execution has to be correlated with a security policy which takes into account not only the access control to the workflow but also the information flow control. This security policy has to be adapted to the dynamic aspect of workflows. It must take into account the progression of the workflow execution and what it can happen at run time. A security policy must satisfy the maximum of security properties. In the following, we give a reminder of these properties: Integrity: this property concerns information and data used within the workflow. These data must not be modified (insertion, suppression,...) by a non permitted access. This property must be ensured especially when output data of a task are the same input data of another task within the workflow and when

26 12 Preliminaries and related works a document can be accessed by different users who may have different access privileges. Authorization: it describes the set of privileges and rights that system subjects can have when accessing the system. These privileges allow the prevention of the non permitted use of resources. Authorization property defines different access rights (read, write, execute,...) to different system users on different objects: the user U has the right R on the object O. Availability: this property concerns the use of different system resources. The execution of a task within a workflow is directly related to the availability of different resources needed to accomplish the task execution and hence the accomplishment of workflow execution. If we suppose that we have two tasks T 1 and T 2 which must be executed in parallel. If these two tasks need a write access to a document D, then the access to the document must not be done at the same time. Thus, at a moment this document will not be available for one of these two tasks. This property depends on the progression of the workflow execution. The availability of system resources is different during the workflow execution. Authentication: it concerns the verification of the identity of the person who will execute a task. This person must have permission to execute this task and must have all privileges allowing him or her to access to different documents and resources needed to execute the task. Thus, the authorization property must be satisfied. This identity verification can be done using pass words, or electronic certificates,... Separation of duty: it specifies that different subjects have to execute a set of tasks. This constraint can be defined within the workflow in order to reduce frauds. This type of constraints can have many categories and they can be evaluated during the conception phase or the execution phase of the workflow. 2.5 Access Control Models Access control models are needed within different system types (data bases, operating systems, networks,...). This is more needed especially when resources to access are very diverse and are shared between different system components. In this section we are interested in some of these models. We do not deal with all access control models. We are concentrated only on contextual models. This choice is done relatively to WFMS. Indeed, when we deal with a workflow, a set of constraints and conditions are defined with the specification of the workflow. Also, a workflow is a

27 2.5 Access Control Models 13 collaborative action, so the set of system resources are shared with different agents of the workflow and these agents can act on these resources or documents at same time or in a very specific order. So, the access control that we have to apply on these systems have to be contextual to satisfy workflow characteristics. Traditional access control models are proved to be not adequate to the dynamic and collaborative aspect of WFMS. These models are particularly based on three sets: A set of objects O: passive entities in the system that may be accessed. These entities represent information needed to execute different activities within the system (for example files,...) A set of subjects S: active entities of the system which will access different system objects. They are entities that will execute requests on the objects (for example users, processes,...) A set of privileges P: rights that subjects can have on objects (for example write, read, execute,...) Basically, an access control policy is a set of relations S x O x P. These relations can be represented conceptually through an access control matrix [HRU76, San92]. The main differences between these models consist on how to group the objects and the subjects and on the privileges defined. These models can be considered as passive models. Indeed, they sum up the access control on the permission granted to a subject to have a right on an object. This definition is too simple and states that an access control is equivalent to checking if the subject has a permission to apply a privilege on the object or not. This simplicity represents the inefficiency of traditional access control models to be active. For this reason, they are inadequate to express different contextual characteristics of an information system. Many works tried to overcome this limitation [AEPO90, AHK + 91]. Then, some trends to define a more active models have reigned. These works suggest constraining access control requirements with contextual circumstances. In WFMS, one may consider the possibility to apply access control models to workflows. In this section we are interested in TBAC, TMAC, RBAC and OrBAC models that are explained in the following sections TBAC: Task Based Access Control model To make access control models more active, [TS93, TS94] have introduced preliminary ideas for TBAC (Task Based Access Control) model. The new idea of this model is to associate the dimension of a task with the access control. It defines a set of protection states representing active permissions maintained for each authorization step. An authorization step, which is represented by a unique protection

28 14 Preliminaries and related works state, corresponds to a task in the system. This notion adds a dynamic aspect to traditional access control models. We notice that this model is more adequate than traditional ones in the context of WFMS. These systems define workflows as a set of tasks. These tasks are inter-dependent. So, such a model can allow us more flexibility to define an access control policy based on workflow tasks and so it takes into account different dependencies existing between these tasks. A security policy based on the TBAC model can be considered dynamic as it depends on the progression of execution of different tasks of the workflow. So, TBAC model manages the notion of usage that it associates to different permissions. Thus, an active permission is not absolute but it has a validity duration which depends on and progress with the task execution. To each permission is associated a counter. When the task related to this permission starts its execution, this counter decreases. When the counter reaches the value zero, the permission is deactivated and the authorization step of this permission is not valid. With subject-object models, granting a privilege to a subject on an object is not relative to any condition or context or precise period. There is no availability context of the permission usage. Figure 2.4 clarifies how TBAC model acts [TS97]. Figure 2.4: TBAC: an active access control model Surely, TBAC model is more dynamic compared to traditional subject-object models, but also presents some limitations. As a matter of fact, TBAC model does not express confinement. So, it does not define how to manage different information flows and how to be sure that no leakage of sensitive information or data will happen.

29 2.5 Access Control Models 15 Especially when we are dealing with WFMS, this requirement is very important. In fact, tasks exchange data and we must pay attention to different communications existing between different workflow agents executing these tasks. An output of a task can be an input to another task. Also, the same subject can be obliged to execute different tasks while having different roles. We have to be sure that this subject will not misuse his rights depending on the roles assigned to him. Thus, TBAC remains insufficient to be used to manage security within WFMS. For this reason, we do not base our work on this model. Other models appeared later and they present other advantages and, thus, are more adequate to be used RBAC: Role Based Access Control model The definition of the RBAC model [ANS04, FSG + 01, FKC03] is based on a simple observation: permissions granted to a subject depend on the role of this subject. For example, all teachers can edit exams but all students can not change exams. Roles are created based on the job functions and/or qualification of users [LBB07]. Then, permissions are granted to users through roles that they have. In fact, permissions are defined relatively to the set of roles defined within the organization or the system where subjects are acting. Different subjects or users are then assigned to different roles. Thus, they get permissions that this role has. The RBAC model was standardized by the ANSI group and it is composed of two essential components: core RBAC and Hierarchical RBAC. RBAC model also considers constraints such as static separation of duty (SSD) and dynamic separation of duty (DSD). It includes not only the administration management [LM07] but also different hierarchies that we can define between different roles [MS93, CIN02]. Also, it deals with delegation issues [MS91, ER00, ZAC02, ZOS03a, RV03]. With delegation concepts, the administration of the model can be distributed and shared between different entities. Figure 2.5 represents a general scheme of this model. The figure represents essential elements used to define permission in the model: roles, objects, operations, sessions. We notice also the assignment of users to different roles (UA) and the assignment of different permissions to different roles (PA). The relation of the hierarchy between roles is also represented (RH). User session function defines a session for a user. The session role function returns the set of roles associated to a session. Finally, constraints of separation of duty are expressed in RBAC by preventing a user to be assigned to two roles in conflict [NO99]. In RBAC model, a user u is prohibited to be assigned to a role r is expressed by the absence of a permission of assigning r to u. With the set of permissions expressed we must be sure that no conflict will happen and constraints will not be violated. Separation of duty (SSD) are applied to UA and RH. So, for the UA function we have to check that no user is assigned to two roles in conflict. For the RH function,

30 16 Preliminaries and related works Figure 2.5: RBAC model we must be sure that through these hierarchies, no user will be assigned to two roles in conflict. However, dynamic separation of duty acts on session roles to avoid having two conflicting roles within the same session. With DSD, a subject can be assigned to two conflicting roles but not at the same time. This is the fundamental difference between SSD and DSD. RBAC model has the advantage of simplifying the subject-object model. Indeed, when permissions are granted to roles and not to users having these roles, the security policy that the administrator must define is simpler and reduced compared to the policy based on subject-object rules. This simplicity makes easy the task of the administrator. Certainly the role notion introduced by RBAC model is useful but this model is still a static model. Since permissions can not take into account different contexts that can be defined with the application, the model can not be considered as a fully dynamic model. RBAC, likewise TBAC model, do not consider confinement when specifying the security policy. So the RBAC model is not very adequate to be used within the context of WFMS. These systems impose specific constraints that must be taken into account when defining the security policy of the workflow TMAC: TeaM based Access Control model The TMAC (TeaM Access Control) model [Tho97] has been introduced after RBAC model and it is based on fundamental ideas of the RBAC model. Contrary to the role notion, TMAC uses the notion of group. We notice that a role and a group do not have the same meaning. In fact, users assigned to the same role form a group but a group is not necessarily a group of users having the same role. So, a group is a set of

31 2.5 Access Control Models 17 users working within the same team and they can have different roles. Generally, this group has a common goal. So the notion of group is very useful within collaborative environments such as those involving workflows [RS94, GHS95]. The goal of TMAC is to apply the RBAC model within collaborative environments. The model defines a collaboration context which must contain two information types: the user context i.e, the set of team users at any given moment and the object context i.e., the set of objects instances required by the team to execute its tasks. So, a team has a set of users, roles, object types, object instances and a collaboration context. The access security policy of a team is based on RBAC model. So security rules are defined as in RBAC model. TMAC defines also the following primitives: User-assign(user, team): assigns a user to a team. User-deassign(user, team): removes a user from a team. Team-activate(team): binds the team permissions to the team members and the objects they need (TU and O). Team-deactivate(team): deactivates permissions for the entire team. Figure 2.6 illustrates these different concepts of TMAC model. Figure 2.6: TMAC illustration Some works have then been done around this model [GMPT01, AC04]. Even if TMAC model introduces the team notion and the collaboration context, it does not

32 18 Preliminaries and related works include different conditions or constraints that can be defined with the application specification. So, it can not really satisfy WFMS requirements, especially on this side. Since, TMAC bases its security rules on RBAC model, it only consider static rules. This model has not been standardized and has not been very developed. For these reasons, this model will not be considered in our work presented in this thesis OrBAC: Organizational Based Access Control model To overcome different lacks and insufficiencies of models presented above, a new access control model has been defined [KBB + 03, CNBSM04], called OrBAC (Organizational Based Access Control). With this model new concepts and ideas were suggested. This model rests on three basic principles: Abstraction of the traditional triples <subject, action, object> into <role, activity, view>. Introduction of organization and context notions. Introduction of negative permissions (prohibitions) and obligations to express security rules. Basic OrBAC concepts: In order to specify a security policy, the OrBAC model [KBB + 03, CNBSM04] defines several entities and relations. It first introduces the concept of organization which is central in OrBAC. An organization is any active entity that is responsible for managing a security policy. Each organization can define its proper policy using OrBAC. Then, instead of modelling the policy by using the concrete implementationrelated concepts of subject, action and object, the OrBAC model suggests reasoning with the roles that subjects, actions or objects are assigned to in an organization. The role of a subject is simply called a role as in the RBAC model. The role of an action is called activity and the role of an object is called view. The entities subject, action and object are considered as concrete entities. An activity is viewed as an operation which is implemented by a set of actions defined in the organization. A view regroups a set of objects to which we can apply the same set of security rules. So, we avoid defining a security rule for each object. These abstract entities are defined within an organization. Each organization can then define security rules which specify that some roles are permitted or prohibited to carry out some activities on some views. Particularly, an organization can be structured in many sub organizations, each one having its own policy. It is also possible to define a generic security policy in the root organization. Its sub organizations will inherit from its security policy. Also, they can add or delete some rules and so, define their proper policy.

33 2.5 Access Control Models 19 OrBAC deals also with different hierarchies that can exist not only between different organizations but also between roles, views, activities or contexts [CCBM04]. The definition of an organization and the hierarchy of its sub organizations facilitate the administration [CCBM04]. Many works have been done to study the administration of this model [CM04]. The security rules do not apply statically but their activation may depend on contextual conditions [CM03b]. For this purpose, the concept of context is explicitly included in OrBAC. Contexts are used to express different types of extra conditions or constraints that control activation of rules expressed in the access control policy. Context is another organizational entity of the OrBAC model. So, using formalism based on first order logic, security rules are modelled using a 6-places predicate: security rule (type, organization, role, activity, view, context) where type belongs to {permission, prohibition, obligation}. As an example, we can define the following security rule: security rule(permission, a hosp, nurse, consult, medical record, urgency) means that, in organization a hosp, a nurse is permitted to consult a medical record in the context of urgency. Basic OrBAC predicates: The OrBAC model defines four predicates: empower(org, s, R): means that subject s is empowered in role R within the organization org. consider(org, α, A): means that action α implements the activity A within the organization org. use(org, o, V ): means that object o is used in view V within the organization org. hold(org, s, α, o, c) means that context c is true between subject s, action α and object o within the organization org. These predicates are represented in figure 2.7. So, from abstract security rules, we can derive concrete rules called CSR using the following generic derivation rule (GR): GR: security rule (type, Org, R, A, V, C) empower (org, s, R) consider (org, α, A)

34 20 Preliminaries and related works use (org, o, V ) hold (org, s, α, o, c) CSR(type, s, α, o) These concrete security rules allow us express a permission of a subject to execute an action on an object. Besides, with the OrBAC model we can express not only permissions but also prohibitions. So, defining permissions and interdictions make the model more flexible but it could raise conflicts. To treat and avoid these conflicts, priorities can be attributed to different rules [CCBG07]. OrBAC goes beyond prohibitions by allowing even the use of obligations. Obligations can be needed to oblige someone to do a specific action in specific circumstances or if a violation is observed. The use of obligations offers us a more flexible control of our system and of processes. OrBAC contexts: Figure 2.7: OrBAC model The context notion that OrBAC introduces represents a very essential notion that can be used within WFMS. These systems need contextual information to express different constraints and conditions defined with the workflow specification. OrBAC defines several types of contexts and defines an ontology of these different types. Within the context of WFMS, three essential types are needed: Prerequisite context: this context enables the definition of initial conditions and special circumstances that we need to specify permissions. Using this context, we can introduce constraints initially defined with the workflow such as the constraint stating that: the task T i must be executed by the same subject

35 2.5 Access Control Models 21 executing the task T j. Besides, we can express separation of duty constraints using OrBAC. Indeed, the OrBAC model defines a special predicate to ensure the separation of duty constraints. The separated role(r1, R2) predicate states that role R1 is separated from role R2, i.e. a subject cannot be empowered in both R1 and R2. In the same way we have separated view(v1, V2), separated activity(a1, A2), separated context(c1, C2) for respectively the view, activity and context separation constraints. Based on the same idea, we can define and express binding of duty within WFMS by defining the predicate same subject(t i, T j ) to specify that two tasks T i and T j must be executed by the same subject. This subject can execute T i and T j either having the same role or also using two different roles. Besides, these different constraints can be considered among the same organization or between different ones. The last case raises more requirements. These transitions between different roles will be studied in chapter 3. Temporal context: this context is very useful within WFMS. It can specify temporal conditions that can characterize task scheduling. So, we can specify that a task must end before a precise time or that a permission is granted to a role under a specific context. For example, the security rule (permission, hospital, physician, consult, MedicalDataBase, after time(08:00) & before time(19:00)) states that a physician within the organization hospital is permitted to access the medical data base only during the working hours, i.e. between 8:00 and 19:00. We can notice in this case that a composed context is used. So, OrBAC offers also the possibility to combine more than one context in the same rule. This possibility simplifies the expression of the security policy and makes it more concise. More details on combined contexts can be found in [CCB08] Provisional context: this context depends on the history of the system states (executed tasks, subject executing previous tasks,...). It requires an execution log to be evaluated. Within WFMS, this context is very important. Indeed, workflows can define constraints related to tasks executed before the execution of a given task. For example, a workflow constraint can state that If the task T i has been executed by the subject Alice then the task T j has to be executed by the subject Bob. Also, we can define that a specific task can not be executed more than twice by the same subject. So, to ensure this type of constraints, we need information about what has happened in the system to be able to satisfy different constraints. In addition to these contexts, the OrBAC model defines a default context which is always activated. This context is especially used when there is no condition

36 22 Preliminaries and related works or circumstances associated with the security rule. Confinement principle: usual access control models does not provide means to express confinement requirement. With the OrBAC model, this principle, which is very essential in security, can be specified and enforced. Indeed, the confinement consists in limiting the area of the security policy defined by an organization. When an organization defines and specifies its security policy, this security policy has effect only within this organization. It applies roles, views and activities of this organization. Let us suppose that we have an inter-organizational workflow where tasks are executed within different organizations. If the specification of the workflow defines a constraint stating that a task T i belonging to an organization Org i must be executed by the same subject who has executed the task T j belonging to an organization Org j (same subject(t i, Org i, T j, Org j )), then the subject, for example Alice, who has executed T j must transit to Org i in order to execute T i. So, when entering the organization Org i, the subject Alice must be granted privileges to execute this task. However, this subject may be not a known subject of this organization. As a matter of fact, this subject may attempt make undesirable data transfers from Org j to Org i. This is more dangerous especially when the organization maintains information having different sensitivity degrees. This transition between different organizations and the information flow that it can imply have to be controlled to avoid a leakage of information. To specify security policies of WFMS, we choose to base our work on the Or- BAC model. With the organization and context notions that this model introduces, requirements of WFMS are taken into account. In fact, contextual circumstances of a workflow execution can be expressed using OrBAC contexts as it is explained above. Also, using organization notion simplifies ensuring confinement aspects. Confinement aspects and information flow control will be also taken into account by enriching OrBAC model. Thus, our approach that we will detail later will be based on defining a security policy which takes into account both access and flow controls. We will define an integrated model where information flow control requirements can be expressed using specific contexts within the rules defined to express the access control. This approach makes the security policy simpler to manage. The chapter 3 presents in details the integrated model that we propose. Then, we show how to manage and deploy such a security policy within WFMS. To show how we deal with information flow control, we present in the following section the most important information flow control models used.

37 2.6 Information Flow Control Models Information Flow Control Models In WFMS, access control models are needed since workflows are characterized by a diversity of resources that can be accessed by different subjects having different roles. Within the context of WFMS, information flows can exist between subjects executing workflow tasks or even between organizations if there are many workflows which are executed within different organizations. These data transfers can be dangerous especially when transferred data are confidential. To avoid leakage of information and misuse of different communications between workflow agents, the use of an information flow control model becomes indispensable. These models try to satisfy some security properties. For example, the Bell and Lapadula (BLP) model [BL73] deals with confidentiality. The Biba model [Bib77] takes into account the integrity property. Other models like the Lipner model [Lip82] try to gather the two properties. In this section, we present a short summary of multi-level security models (MLS) and particulary the BLP model. We show why we will not use them to deal with information flow control. We notice that we replace the use of MLS models by using a more flexible model for information flow control, says DTE Multi Level Security models: Bell-LaPadula model MLS models are based on classification of system information or data and on a classification called clearance assigned to users. From these classifications comes the term multi-level. The information classification is done through levels of trust and sensitivity that the information can have. These levels represent the well-known security classification: Unclassified, Confidential, Secret, and Top Secret. This is represented in figure 2.8. the dashed arrows illustrate the direction in which the security rules allow data to flow. So, only one direction is permitted, from lower levels to higher levels, the opposite direction is not permitted. MLS models do not only classify information but also persons who want to access these information. To each person they assign a clearance. This level indicates about the degree of trust given to this person. When persons need to access these classified information they must refer to their clearances. Persons having a Confidential clearance are authorized to see Confidential documents but they are not allowed to look at Secret or Top Secret information. These models have been especially used within military applications to guarantee confidentiality. The model the most used as a formalization of MLS is the Bell Lapadula (BLP) model [BL73]. This model is especially used within military applications to define policies guaranteeing confidentiality. Based on this security policy, a system is defined as a state machine. So, a system is defined to be secure if the only permitted access modes of subjects to objects are in accordance with the security policy. To

38 24 Preliminaries and related works Figure 2.8: The hierarchical security levels determine if accesses are allowed or not, the model is based on the clearance assigned to the subject and on the classification associated with the object. These security levels are then compared and they have to satisfy two mandatory access control (MAC) rules or properties: 1. The Simple Security Property: a subject at a given security level may not read an object at a higher security level (no read-up). 2. The *-property: a subject at a given security level must not write to any object at a lower security level (no write-down). The *-property is also known as the Confinement property. The first security rule specifies that a subject must always have a trust level superior to the one of the object that she will read. By prohibiting a subject to read from objects having a higher classification, we can ensure that a leakage can not been done when such an access is done. The second rule stipulates that a user has a right just to write (create content) on documents having a classification equal to or higher than the clearance of this user. For example, Secret researchers can read Secret or Unclassified files but not Top Secret files (no read-up). However they can create Secret or Top-Secret files but they can not create Unclassified files (no write-down). On the one hand, we can notice that within BLP model, only two actions are considered, read and write. Within the BLP context, write action can include

39 2.7 Related Works 25 implicitly create, delete or alter actions. But, it is obvious that we can have much more activities and actions to apply on an object. Especially within the context of WFMS, these actions can really vary and may be actually more complex. On the other hand, the simple security property can be considered clear and obvious. However, the second rule can raise a problem. Indeed, clearances and trust degrees are associated to users, but subjects can be programs. These programs can contain a trojan horse. Particularly, within multiuser systems, people with different clearance levels could work at the same time and everyone should be able to share programs and files. Through a program containing a trojan horse we will be able to access documents that we do not have the privilege to access. Besides these gaps within BLP model, MLS models can be considered enough constraining. In fact, assigning trust levels to subjects and objects adds an additional management of these levels and requires an efficient administration procedure. So, these new functionalities are able to make the system much more complicated. In addition, management of these needs in these models is still static and centralized. Notably this is more remarkable with WFMS, which present at first a large diversity making them more difficult to manage. For these reasons, within this thesis we choose to go beyond MLS models to manage information flow control DTE: Domain Type Enforcement To manage information flow control, we will be based on a more flexible model than MLS models, called DTE (Domain and Type Enforcement). This model offers more flexibility to manage information flows. It is simply defined and does not require to classify objects and subjects. DTE is based on two matrix to define and manage access to different objects and interactions existing between different subjects. The first matrix can be considered an access control matrix. The second deals with information flow control. For these reasons, our information flow security policy will be based on this model. This model will be presented in details in chapter Related Works After this short overview of main access control and information flow control models, we now move to the presentation of models specifically designed for WFMS security. Actually, many works have been done around the security within WFMS and generally within collaborative environments. First, we start by works done within pervasive workflows and based on onion encryption techniques to make secure the workflow execution. Then, we discuss related works on access and flow control in WFMS. Finally, we reference some works done to manage security policies in the context of collaborative environments since WFMS are a significant example of these

40 26 Preliminaries and related works environments. Notions which will be presented in this last section will be used in chapter 5 of this thesis. We have discussed these related works in [ACBC08b] Workflows Security Based on Onion Encryption Techniques Works done in [MM07a, MM07b] have been interested on the security of worklows when they are executed in a decentralized manner. They consider pervasive workflows where agents executing different workflow tasks are selected at the run-time. This selection is essentially based on the availability of resources and agents. On the one hand, these works are interested on the functional part of pervasive workflows. So, they deal with the workflow coordination and management tasks based on a dynamic assignment of business partners to workflow tasks. Therefore, they propose a transactional protocol to assure their coordination from the transactional point of view. On the other hand, they try to assure a secure execution of different workflow instances. Their approach is based on onion encryption techniques [SGR97]. They try to ensure a secure communication of different workflow agents and ensure the integrity of the workflow. They are based on assignment of key pairs to different vertex of the workflow. They present how to manage these keys in order to make communications intra-workflow secure and define schemes to protect the data transferred between agents. Using these different mechanisms, they show how they can be able to support the secure execution of a workflow in the decentralized setting. The study done in this work is based on web services as an application platform of WFMS. The difference between the aforementioned work and the work presented in this thesis is twofold. On the one hand, in this thesis we consider a decentralized approach of WFMS but using an infrastructure existing aforehand. In other words, before starting the workflow execution, we know agents that they will execute different worflow tasks. We do not search for them during the execution of the workflow and just before starting the execution of a specific task. However, we do not only consider a central entity which has a global vision of the wokflow and which is responsible for the functional and security parts of the workflow. We consider a decentralized vision of the workflow where different workflow agents can participate either in the functional part of the worflow or in ensuring the security of the workflow. On the other hand, our approach to tackle the security in WFMS is not the same as in the work mentioned above. We do not deal with cryptography aspects. We try to ensure the security of the workflow based on access and flow control models. Surely, using these models we do not take into account the access to different resources but also the security and the integrity of transferred data within the workflow. Also, we do not apply our approach just to web services but we remain general when talking about WFMS. So our security approach is very different from that based on

41 2.7 Related Works 27 encryption techniques Specifying Access and Flow Control Within WFMS Access Control WFMC: WFMC (Workflow Management Coalition) is an international organization focusing on the development of workflows through standards that provide connectivity between different products. WFMC suggests WfRM as a model of reference for workflows. This reference model is represented in figure 2.9. It presents a management system of workflows and their different interfaces. WFMC defines different services to ensure a secure environment: identification, authentication, authorization, confidentiality, integrity and non repudiation. [Coa95] studies these services using WfRM. WfRM defines three functional areas. The first consists of different functions of the building phase of the workflow. The second, includes different procedures of control and interoperability (run-time process control functions). It also includes the definition of different workflow instances. The third area deals with the interaction of the workflow with system applications and users. Besides, WfRM specifies 5 interfaces represented in figure 2.9: Interface 1 represents the transition from the real representation of the workflow to a formal representation of the workflow. Interface 2 manages the communication between the workflow and the workflow client applications. Interface 3 is in communication with invoked applications Interface 4 deals with the interoperability between different workflows (an inter-workflow interface) Interface 5 manages the administration of the workflow. Works done by WFMC are especially interested in the functional part of WFMS. From the security point of view, WFMC suggests a simple security model [Coa98] which defines a set of security operations. This model can be considered too simple compared to security requirements and problems that can raise the execution of a workflow or of a set of interoperating workflows. It does not go further than basic security properties that it tries to define. It defines an authentication service for users participating in the workflow execution. This service will be responsible for assigning authorizations and so privileges to access resources and execute workflow tasks. Its access control model is limited to these static privileges assigned at the beginning of the process. Besides, this access control model does not take

42 28 Preliminaries and related works Figure 2.9: WfRM reference model into account different interactions that can be present between different workflow agents and different execution orders that can characterize a workflow. Therefore, this access control model is not only very local to the system to access but also it is centralized. Information flow requirements have been left aside. The only potentially interesting concept that WFMC introduces within security aspects is the common security profile. This concept is used to manage the interoperability between different workflows. However, we can notice that even this concept is not very adequate to the WFMS context. Indeed, the use of this concept is based on a very constraining hypothesis: two workflows must use this common profile initially and statically defined during whole workflow execution. On the one hand, this approach does not consider different constraints that a workflow specification can present. On the other hand, many changes can take place during all the workflow execution so the access control has to be updated according to these changes. This approach does not consider the flow of authorizations among parties, tasks and resources during the workflow execution. WAM: [AH96, AAH98] propose a conceptual and a logic model called WAM (Workflow Authorization Model) to enforce the authorization flow based on the interdependencies between tasks using colored and temporized Petri nets. The model defines an authorization template (AT). These ATs are defined during the building phase and they are used to derive the actual authorization during the execution

43 2.7 Related Works 29 phase. WAM tries to synchronize the flow of authorization with the workflow and to specify temporal constraints using a static approach. Different algorithms and interpretations of modeling are presented in [AAH98]. WAM has the same general motivation as TBAC in that it tries to provide some notions of active security and just-in-time permissions. In TBAC an authorization-step has a larger meaning and can be considered an abstraction to model and manage a set of related permissions. In WAM an authorization is a more primitive concept and represents the fact that a subject has a privilege on an object for a time interval. This model does not consider neither the order of execution of tasks for the same object nor the authorization access to resources. Their approach remains also static. Based on the WAM model, Atluri and Huang have developed in [HA99] a model called SecureFlow for the web in WFMS. The model uses a simple language of 4G to specify different constraints on authorizations. It has a modular architecture composed of four components: WDSM (Workflow Design/Specification Module), WES (Workflow Execution Server), WAS (Workflow Autorisation Server) and the WC (Workflow Client). [HA99] defines the functionalities of these components and the specification of constraints and the security policy associated with the model. Both WAM and SecureFlow are only adequate for centralized management of workflow security. A central entity is responsible for managing different ATs (Authorization Templates) that must attribute to different workflow agents. Also WAM is based on assigning execution intervals to different workflow tasks. Such an hypothesis is not very realistic. As a matter of fact, in real workflows we do not have always the possibility to limit the execution interval of a task. Besides, the security policy of the model is based on the RBAC model to define different authorizations. Since the RBAC model is still static, WAM could not go away from this limitation by just adding execution intervals. This choice further constrains the workflow instead of making its security more dynamic. Therefore, the model does not take into account the history of executed tasks. This history could be very important within the context of WFMS. For example if we have two tasks T 1 and T 4 which must be executed by the same subject and T 1 is executed before T 4, then, before starting T 4 execution, we need to know which subject has executed T 1. A provisional context can provide us with such information. Hung and Karlapalem [HK99] have presented another authorization model for WFMS based on the RBAC model. This model addresses three security properties: integrity, authorization and availability. The model is based on defining a set of invariants. These invariants deal with several aspects: agents, events and data of the workflow. The model is defined as an abstract machine having three layers: workflow layer, control layer and data layer. The first contains authorizations which can be granted to or revoked from an agent. The second deals with events which

44 30 Preliminaries and related works can be generated during the execution phase. The last layer manages granting and revoking authorizations to documents. Security requirements are then transformed into a set of invariants in different layers. Using these invariants, authorizations functions are defined in order to ensure system operations. In spite of supporting concurrent execution of tasks, the model does not address different temporal constraints. This type of constraints can not be neglected since it represents an indispensable requirement of workflow specification. A workflow execution is especially based on scheduling of tasks. [BFA99] studies authorizations in WFMS considering different constraints. Based on the constraints associated with temporal control, they define three classes of constraints: static constraints, dynamic constraints and hybrid constraints. These constraints are defined as clauses in a logical program to check their consistency. This work is based on assigning users and roles to tasks. These assignments lead to the definition of RAG (Role Assignment Graph) and URAG (User Role Assignment Graph). These graphs define different roles and users authorized to execute a task. This is done for all tasks of the workflow. So, these graphs define all possible assignments that can be done for a workflow execution. This work ensures the non violation of constraints by defining only valid paths when assigning users and roles to different tasks. However, this approach can lead to a combinatorial explosion and can have an exponential complexity especially when the workflow contains a large number of tasks, users and roles. Therefore, it can make the system management enough complex just to be sure that constraints are not violated. Also, this model does not address temporal constraints and constraints based on events. It supposes that tasks are executed in a sequential mode. In the case where two tasks are executed in concurrent mode, it is impossible to define constraints on a task based on the success or failure of other tasks. Thus, this model cannot be considered complete and does not address the issue of distributed management of workflow security requirements. Multilevel secure workflows: other works have been interested in studying different aspects of WFMS security. [AHB98] describes a security model to be applied in multilevel workflows. Within these workflows, tasks can belong to different security levels. Also, dependencies between these tasks can be either from lower level tasks to higher level tasks or from higher level tasks to lower level tasks. This latter type of dependencies can raise problems to satisfy workflow security. The work done in [AHB98] is especially based on a very detailed classification of different types of dependencies. A first general classification divides these dependencies into three classes: flow control dependencies, values dependencies and extern dependencies. Other classifications define several other classes:

45 2.7 Related Works 31 conflicting class if the tasks dependency causes a conflict (for example to access the same resource), if not we talk about conflict-free class. result-independent class if the result of the second task does not depend on the result of the first task. If not, we talk about result-dependent class. weak (for example a task can not start until another task commits) and strong (for example, if a task commits, another task must end) dependencies. abortive and non abortive classes to specify if the result of the second task of the dependency corresponds to an abort activity. This work proposes algorithms to view a workflow with a new conception based on these different dependencies. This conception tries to not violate different constraints and dependencies defined in the workflow specification. This work is not interested to different cases when two tasks are dependent of each other and they have to access the same resources. It does not take into account management of the access to system resources which can raise problems when ensuring dependency constraints. Besides, assigning different levels to workflow tasks makes the workflow more and more constrained and so more complex to be managed Flow Control In previous works, most approaches take into account access control within WFMS. However, studying information flow control within these works has not been investigated. Nevertheless, there are trends to specify both access and flow control in a system. Very few works tried to apply this convergence of access and flow control to WFMS. So, in this section, we try to go around these different works to show how this convergence is defined. Nyanchama and Osborn have initially addressed the issue of combining the RBAC and Bell-Lapadula (BLP) models in [NO94]. They examined the application of information flow analysis to role-based systems. Thus, [NO94] defines a flow policy which describes the authorized flows in the system. It classifies flows in different categories. Then, during process execution we must derive the set of flows generated. The two sets are compared to deduce and ensure that a given role-based scheme is consistent with the specified policy defined with basic flow axioms. Also, to determine this consistency, [NO94] uses graph theory to deal with the issue. It considers the set of roles and the role-based protection scheme and it draws a graph G1 to represent actual potential flows. A second graph G2 represents relations between flows defined in relation to the flow policy. It defines categories as nodes and edges as permissible information flows between categories. A role-based scheme is

46 32 Preliminaries and related works consistent with the system security policy if and only if the former graph is a subgraph of the latter. After this first tentative, Nyanchama and Osborn have tackled the issue with a different approach in [NO96]. In fact they introduced the notion of context. A context is viewed as the set of information accessed via a role. Using this concept, [NO96] proposes a realization of mandatory access control in role-based protection. In their formulation, role contexts are treated as the equivalent of security levels. They consider two issues. The first is an acyclic information flow among role contexts. The second is equivalent rules to the simple security property and *-property of traditional multilevel security. [NO96] proposes a number of access constraints that would realize the equivalent of BLP rules. Finally, it concludes that in MAC, information flows must be acyclic. So the approach proposed ensures that information flows, caused either by role execution or user-role assignment, will be acyclic. In [Osb97], Osborn was based on Nyanchama model described in [NO96]. She considers details of a single role or node and a given edge. Then, the model determines under what conditions such structures violate MAC constraints. [Osb97] defines a more detailed structure. The new graph contains assignable roles. So it is very restricted compared to general role graphs. In other words, it is more interesting to analyze every role and every edge in a general role graph to check if roles are assignable, and at what levels they are assignable. Sandhu was also interested in the issue but he follows another direction [San96]. His approach represents another vision of simulating MAC controls in RBAC models. It is based on configuring RBAC components. It considers similarities between MLS security levels and RBAC roles. So a role is identified to a level of a login session. Its basic idea is to suppose two hierarchies in RBAC model, one for read and another for write. Thus, to each user we assign two roles, one for read (RR) and one for write (RW). Consequently, permissions are divided into groups of read and write privileges and so they must be assigned separately to RR and RW. [San96] examines different variations of lattice based access controls (LBAC) and translates each of them into a role hierarchy. It defines a construction using a single pair of roles to accommodate lattices with different variations of the *-property. An extension of this work is presented in [OSM00] and [SM98] considering different DAC variations. [OSM00] focuses on the importance of the administrative aspect. An implementation of these ideas can be found in [Dem01]. In [Kuh98], Kuhn uses a construction of a role hierarchy. He defines an assignment of object categories to privilege sets and an assignment of categories to roles. So, to each role it assigns the categories associated with its privilege set and categories associated with privilege sets of its ancestors. The first limitation of this work is related to category mapping which must be regenerated if changes are made in the role structure. The second is that the hierarchy created by the algorithm must

47 2.7 Related Works 33 be a tree, rather than a lattice hierarchy. Atluri, Huang and Bertino have used a convergence between RBAC and MLS to apply it to WorkFlow Management Systems. They define in [AH97] and [AHB98] models of WFMS based on Petri nets and consider an RBAC security policy. They assign levels to different objects used in the system and so to tasks using these objects. Then, they apply the MLS approach to their model taking into account different task dependencies. But their approach is restricted to fully secure and partially correct workflow execution. In other words, the approach does not enforce all task dependencies. So it can affect functional workflow execution Discussion Different works trying to specify access control within workflows present many limitations which can be summarized in the following points: Centralized management: different previous works consider a centralized view of the workflow. A central entity has a global vision of the workflow and manages its security policy. Static approach: since the security policy of aforementioned works is based on the RBAC model, their approaches can be considered static which is not appropriate to WFMS known to have a dynamic behavior. The standard RBAC model is not able to take into account contextual information of the workflow and is not able to define confinement between different organizations that participate in the workflow execution. Sequential order of tasks: most works consider that workflow tasks are executed in a sequential order. This hypothesis is too far away from reality. Workflow tasks can be executed in different execution orders: sequence, parallel, concurrence. Do not take into account these execution modes can affect the correct execution of the workflow. Deployment: once the policy is specified, these works do not show how to deploy this security policy during workflow execution. The workflow execution can affect this policy which must be updated according to different task executions and possible changes that can happen. Inter organizational workflows: these different works consider only the simple case of an intra-organizational workflow where all tasks belong to the same organization. If these tasks are executed within different organizations, the problem becomes more complex.

48 34 Preliminaries and related works Information flow control: it is not considered in the most of these works. Even several attempts to define a convergence between access and flow controls requirements exist but they raise several problems. The models used to define such a convergence, namely RBAC and MLS models, are not very adequate. The convergence based on these models creates an inconsistency which will be futher detailed in next chapter 3. In the present thesis, we try to remedy to these different lacks. Our principle approach will be based especially on these basic ideas: We choose to base our security policy on the OrBAC model to make the security policy more dynamic. We integrate flow control to the access control model in order to use one integrated model to manage both access and flow controls within WFMS. We define a decentralized procedure to ensure a secure environment for the workflow execution. We consider different constraints that can be defined by the workflow specification especially temporal constraints. We define an approach to show how to deploy our security policy once it is well defined. We consider not only the intra-organizational case but also the interorganizational case of workflows. To manage this latter case, we will need to introduce a virtual organization to deal with the inter-organizational policy. Thus, in next section we go around some works done within collaborative environments and which introduce and use the notion of virtual organization (VO) Collaborative Environments: VO management WFMS are basically defined as collaborative environments, where a common goal is sighted. All parts of the workflow have to participate to achieve this goal. So, to interoperate, these different parts will have communications and exchanges between each other. The security requirement in this case becomes more critical. So, these interactions have to be secure in order to keep a harmony and a secure environment of workflow execution. The interoperability between different organizations has been the subject of interest of [CCBC06]. In this work, a new approach called O2O (for Organization to Organization) has been defined. This formal approach deals with collaborative environments which include more than one organization having

49 2.7 Related Works 35 to interoperate in order to achieve a specific goal. These organizations can share services or resources or even users. So, this interoperability must be secure. To manage the security of this interoperability, the concept of Virtual Organization has been used. The concept of Virtual Organization has been proposed in [Mow77, RKC98] to avoid limitations of client/server architectures. A virtual organization is defined through different organizations and it is composed of users, resources and services belonging to these different organizations. It ensures interactions between different organizations to exchange information or resources or roles. Figure 2.10 represents the principle of this concept. In O2O, when an organization accept to interoperate with another organization, it creates a Virtual Private Organization (VPO). Each organization belonging to the virtual organization is responsible for controlling its interoperability access through the definition and the administration of its VPO (Virtual Private Organization). In O2O, the objects are always controlled by their organizations. So, the interoperability is defined through three type of organizations: 1. O grantor: the organizations which possesses the required resource. It has a local security policy. 2. O grantee: the organization which needs the access to the resource. 3. VPO: the organization which administrates the interoperability policy. The VPO defines privileges on subjects of O grantee when they access to O grantor. In O2O, the security policy of a virtual organization is the union of all VPOs. To manage the security policy of this VO, three approaches have been defined: centralized, decentralized and hybrid approaches. The centralized approach consists in managing the VPO through a confidence server. In the decentralized case, the organization manages and administrates its VPO. The hybrid approach is required when some organizations do not have confidence on the centralized server. In this thesis, we will deal with inter-organizational workflows. To manage the security policy in this case, the concept of virtual organization will be used in chapter 5. We will present how a virtual organization will be created and how it will be used to ensure a secure environment of interoperability between different organizations. We notice that in our work we will be especially interested in the transition of different users between different organizations in order to enforce workflow constraints. This case is very interesting especially when the subject has to change its role when accessing to another organization.

50 36 Preliminaries and related works 2.8 Conclusion Figure 2.10: Virtual Organization Principle In this chapter we introduced WFMS and their different security requirements. We show that these systems need more than one model to specify these security requirements. Besides, we go around different previous works which have been done to study the security of WFMS. We noticed that these models presents numerous limitations. So, to overcome these limitations we choose a different approach to specify our workflow security policy. This approach is based on the definition of an integrated model which deals with both access and flow controls. The definition of this integrated model is based on the OrBAC model and uses DTE concepts to integrate flow control requirements. On the one hand, OrBAC is used because it offers a sufficient expressivity to express dynamic security rules using organization and context notions. On the other hand, the choice of the DTE model is done to go beyond rigid constraints of MLS models. Next chapter 3 presents the integrated model that we propose. Then, in chapter 4, we show how to model and specify a secure workflow. However, chapter 5 discusses how to manage and deploy our security policy once it is well specified.

51 Chapter 3 An integrated model for access control and information flow requirements 3.1 Introduction With the diversity of possible attacks on an information system and with the different security properties to be ensured, maintaining and guaranteeing system security is becoming an increasingly complex task. On the one hand, to protect a system, we must control all actions done from the beginning until the end of the user s sessions. So, a user must be authenticated and must be controlled when accessing objects. All actions that this user performs in the system have to be authorized. On the other hand, information systems present multiuser aspects and they manage interactions between different system parts. These interactions must be also supervised since they can lead to misuse of system s objects or to compromise of the system s integrity. To address these different issues, many models were proposed to satisfy different security requirements of a system [San93]. There are models which are interested in integrity and confidentiality properties. Other models are interested in usage control and others in flow control. To secure a system, more than one model must be used since security requirements are as various as the diversity of these models. But there is no model that gathers these different security concerns. Workflow Management Systems are a very significant example of systems which need more than one security control model. This is because they not only present a diversity of objects and users but also various dependencies between different tasks and so between users. Access to the same object can be needed simultaneously, also writing on documents and modifying them must conform to the execution order. Moreover, the information

52 38 An integrated model for access and information flow requirements flow has to be checked. All these system constraints have to be managed with a global security policy. This policy must deal with access and flow control requirements. Several works were done in order to converge access and information flow control. Several authors have discussed the relationship between RBAC and MLS lattice based systems [NO94, NO96, San96, Osb97, Kuh98, OSM00, Dem01, SM98, AH97, AHB00]. All these works have been analyzed in the previous chapter. The basic idea that we retain is that the majority of them are founded on a mapping of RBAC notions and MLS notions. In these models, subject clearances are used to create roles associated with security levels in a role-based system. Beyond the limitations of MLS models, we consider that such a correspondence is a misunderstanding of MLS notions. We go in further details in the following section. In this chapter, we present a convergence of access and information flow controls which is based on two models, namely OrBAC and DTE. Thus, the contribution of this chapter is twofold. First, we go beyond MLS models as a representative of flow control models. For this purpose, we base our study of flow control on a more flexible model which allows us defining a flow control policy more flexible than MLS constraints, say the DTE (Domain Type Enforcement) model [BSS + 95, TP97, KW03]. We take close interest in this model, we explain our proper vision of it and finally we formalize it in order to use it to define our integrated model. Second, using DTE, we need to specify contextual rules to express a security policy which manages information flows and object accesses. For this purpose, we suggest using the OrBAC model [KBB + 03, CNBSM04]. In the OrBAC model, security rules are contextual. This characteristic of OrBAC security rules is necessary and sufficient to take into account information flows control. Later, we will show how this contextual aspect can be used to define an integrated model dealing with access and flow controls. Moreover, OrBAC is able to express confinement requirement, a key concept in security management of complex systems. The entity organization defined in the OrBAC model allows us to handle this aspect. Combining OrBAC access rules and a formally stated DTE model, we present a different model to integrate access control and information flow requirements. This integrated model defines rules that we have to apply to our workflow model in order to control its execution. In this chapter, only the convergence is defined, we define how to express information flow control and access control using the same concepts and rules. In chapter 4, we will show how to apply this new rules definition to the workflow model. Such an integrated model simplifies the security policy management. The administrator will not be obliged to manage different models having different basis and different concepts to deal with the workflow security. So, the definition of this convergence makes homogeneous the security policy definition since our policy server will deal with the same type of rules based on the same concepts and having the same format. We have published the work done in this chapter in [ACBC07].

53 3.2 Motivation 39 The remainder of this chapter is organized as follows. Section 3.2 provides different motivations for this work. Section 3.3 clarifies DTE principles and especially the entry point notion. Section 3.4 defines our DTE formalism. In section 3.5, we introduce and exemplify our integrated model for access and information flow control. Finally, we conclude this chapter in section Motivation Various previous works are essentially based on the same idea. They define mapping similarities between RBAC and MLS systems. The choice of RBAC is done to handle access control. Then, a mapping of MLS levels is done on system roles. They investigate clearance notion present in MLS systems and they apply it to roles. Thus, using a mapping between RBAC roles and MLS clearances they associate a clearance with each role. There is actually nothing wrong with identifying a role with a clearance level and assigning users to these roles. What is wrong in these approaches is to apply the BLP principles to the role behavior, especially the *-property. To illustrate our claim, let us consider an MLS application that manages classified objects and provides means to declassify or encrypt these objects. In the RBAC policy, one may consider that users assigned to the role R secret (corresponding to the secret security level) are permitted to declassify and encrypt secret objects. Now, let us consider three different scenarios: 1. A user logs in the application at the secret level and attempts to declassify a secret object. 2. A user logs in the application at the secret level, creates a digest of a secret object and attempts to declassify this digest. 3. A user logs in the application at the secret level, has an access to a secret object using a browser and attemps to declassify this object through this browser. We can consider that the first scenario is secure if both the login and declassification functions are trusted (i.e. they do not contain a Trojan Horse) and the secret object to be declassified has high integrity (i.e. this object has not been previously manipulated by a malicious application which hides some secret data the user did not want to declassify). This scenario actually corresponds to a robust declassification as defined in [MSZ04]. Regarding the second scenario, it is also secure if the application used to create the digest is a trusted function. Finally, regarding the third scenario, it is not secure if we consider that a browser is not a trusted application since this browser may call the declassification function to illegally declassify other objects. Notice that the conclusion would be the same if we replace declassification

54 40 An integrated model for access and information flow requirements by encryption in the third scenario because a malicious browser could use the fact that an object is encrypted to create an illegal covert channel. Now if we apply the BLP principles to the role R secret, then these three scenarios will be considered insecure since they all violate the *-property principle. This is clearly unsatisfactory. This is why we claim that it is incorrect to identify roles with clearance levels and then apply the BLP principles to these roles. Actually, the BLP principles apply to processes acting on behalf of users to prevent these processes from creating illegal information flow when they contain a Trojan Horse. By contrast, roles should define permissions of user, not of processes. Therefore, all previous works are based on BLP model to ensure flow control. This model present some weaknesses. Although it is able to protect a system from a Trojan horse used to access a document, BLP is unable to prevent a Trojan horse from altering or destroying data as it permits processes to write into files they can not read. BLP can not detect covert channels and remove them. As an MLS model, it is unable to be used to define policies outside multilevel security, which is restricted to specific applications. To go away from these different constraints and drawbacks, we propose in this thesis to use another model more flexible to control information flows, say DTE. DTE is presented in the following section. Besides, information flows are generally conditioned by program executions or generated after a process execution. For this reason, flow control must be contextual and not exclusively role dependent. Thus, to specify our integrated model, we choose using the OrBAC model instead of the RBAC model since it permits us defining contextual and dynamic rules. OrBAC also allows us to express the confinement principle based on clear separation between the different authorities (organizations) who define and manage the security policy. So, our security policy is expressed using OrBAC contextual security rules and integrated DTE concepts. In this way, with the integrated model we propose, we ensure fine grained access control and manage more flexible information flow requirements which are not constrained by strictness of security levels. 3.3 DTE principles DDT and DIT tables In a system execution, processes dependencies and users interactions include data exchange. Information flows can be either explicit (as in assignment statements) or implicit (as in conditional statements) [Liu80]. It can be due to functional dependency (e.g. x depends on y, hence there is a flow from y to x), or deductive (if knowing the value of x implies knowing the value of y, hence there is a flow from y to x) [Mil81]. These data may have different sensitivity levels. So, if no security mechanism is applied on such exchange, the data transfer between processes may

55 3.3 DTE principles 41 lead to leak of confidential information and to misuse of some documents or information. To limit the damage that can be caused, confinement mechanisms have been developed [BK96, BKY85]. They are based on the idea of restraining the privilege access of subjects on objects. So, confinement aims to restrict actions of programs in execution. BLP was the first model developed to address this issue and to deal with flow control. But it has some weaknesses we had already explained. Away from multilevel security domain, the DTE model has been developed to satisfy security requirements of a system. Since there is no works which detail all DTE functionalities as they were specified, we propose in this section to clarify this technique and give our proper vision regarding the DTE concepts. Domain and Type Enforcement (DTE) [BSS + 95, TP97, KW03] is a technique originally proposed to protect the integrity of military computer systems and was intended to be used in conjunction with other access control techniques. As with many access control schemes, DTE views a system as a collection of active entities (subjects) and a collection of passive entities (objects) and groups them into domains and types. This classification not only reduces the size of the access control matrix but also simplifies its management. DTE defines two tables to base its access control definition. The first table is a global table called Domain Definition Table (DDT). It governs the access of domains to types (domain-type controls). Each row of the DDT represents a domain and each column represents a type. When a subject attempts to access an object, we must verify the entry corresponding to the domain of the subject and the type of the object in the DDT. If the access needed is defined in the table then the access is allowed, if not, the access is denied. The second table is called Domain Interaction Table (DIT). It governs the interaction between domains (Inter-domain controls). Each row and each column of the DIT represent a domain. The intersection cell denotes the access privilege that the domain corresponding to a column possesses on the domain corresponding to a row Domain transition problem and entry point notion Since DTE has been used and implemented in SELinux, we use this system to explain the problem that can arise when transitioning between different domains. Let us consider the passwd process presented in figure 3.1. This process can access the /etc/shadow file. It is trusted to read and modify this file. Let us suppose that a user Alice logs in and thus a shell process is created (bash). The real and effective user IDs (uid, euid) are Alice. By default the process type used will be user t, which is the ordinary type of non trusted user processes. As the Alice s shell implies the execution of several programs, new created programs on Alice s behalf will have access to the user t type. If Alice wants to change the file /etc/shadow then we have to be sure that this action will not be performed directly. Otherwise, any

56 42 An integrated model for access and information flow requirements program would be allowed to change the content of this critical file. Since we want that this file is accessed only through the passwd process and using the passwd t type then we have to find a secure method to transit from Alice s shell running with the user t type to a process running the passwd program using the passwd t type. Figure 3.1: The problem of domain transitions Concretely, this transition corresponds to different role changes that can occur within an organization. For example, when a department manager is on holiday another person (generally the most trusted and having the closer grade to this manager) will replace him. This transition must be very secure especially if the new domain where the subject transits maintain information of a certain sensibility degree. Also, this transition must not transfer all the manager s privileges to this new person. So, being in the new domain or having a new role is a controlled and temporary task to achieve a specific activity. To be complete, DTE has defined the manner to be used to pass from a domain to another. So, if a subject S belonging to a domain D 1 wants to pass to a domain D 2, it must refer to the DIT. The intersection of D 1 and D 2 in DIT should contain an entry indicating the activity or the program that S must perform to access to D 2. This entry is called the entry point. Thus, each domain has one or many entry points which consist in programs or activities to be invoked by a subject in order to enter this domain. Any subject belonging to another domain must execute an entry point of the destination domain to be able to access this domain. The entry point permission defines which executable files (and so programs) may enter a domain. for a domain transition, the new or to-be-entered domain must have entry point access to types used to transit. When passing from a domain to another, a subject looses all its privileges of the source domain and gets a privilege set in destination domain. This privilege set depends on the executed entry point. If the domain allows transitions without defining specific entry points a default domain transition is done. This default domain transition do not contain any conditions to access the domain.

57 3.3 DTE principles 43 This type is usually used with domains which do not maintain sensitive information and may be publicly accessed. The notion of entry point makes the inter-domain communication more strict and precise. This concept is extremely important since it strictly defines who can access what and in which manner. This is a powerful security control An example of DTE policy To further explain a DTE policy let us consider figure 3.2. It presents a DTE policy defined for Unix system. In this specification, Types declare one or more object types to be available to other parts of a DTEL (Domain Type Enforcement Language) specification. Domains declare different domains. Then, a domain specification is expressed as a list of tuples. It defines a restricted execution environment composed of four parts: 1. entry point programs, identified by pathname, that a process must execute in order to enter the domain (e.g., (/bin/bash)) 2. access rights to types of objects (e.g., (rwxcd root t)) 3. access rights to subjects in other domains ( e.g (exec root d)). A DTEL domain controls processes access to files, processes access via signals to processes running in other domains, and processes ability to create processes in other domains by executing their entry point programs. If a domain A has auto access rights to another domain B, a subject in A automatically creates a subject in B when it executes, via exec(), an entry point program of B 4. signals exchange between processes of source and destination domains. Assign associates a type with one or more files. Policy of figure 3.2 shows how to protect a system from the wu-ftpd vulnerability to prevent an attacker from obtaining a root shell. This policy example will be reused in section to illustrate our integrated model. All works done around DTE use DTEL to specify the security policy. No reflection has been undertaken until now to formally define and use the DTE model. Such a formalism will provide means to specify expressive security policies. In this chapter, we propose to define a formalism allowing us to define merely a security policy which takes into account the flow control between system entities. Afterwards, this formalism must be blended with an access control model in order to deal with flow and access control simultaneously. This twofold control could make our security policy more useful and increases assurance that it is correctly specified. The premise of this formalism is that access control is based on domains

58 44 An integrated model for access and information flow requirements and types. It provides facilities to express relationships between system entities. Thus we do not define a new model but an integrated one. 1 ftpd protection policy 2 types root t login t user t spool t binary t lib t passwd t shadow t dev t config t ftpd t ftpd xt w t 3 domains root d login d user d ftpd d 4 default d root d 5 default et root t 6 default ut root t 7 default rt root t 8 spec domain root d (/bin/bash sbin/init /bin/su) (rwxcd root t rwxcd spool t rwcdx user t rwdc ftpd t rxd lib t rxd binary t rwxcd passwd t rxwcd shadow t rwxcd dev t rwxcd config t rwxcd w t) (auto login d auto ftpd d) (0 0) 9 spec domain login d (/bin/login /bin/login.dte) (rxd root t rwxcd spool t rxd lib t rxd binary t rwxcd passwd t rxwcd shadow t rwxcd dev t rxwd config t rwxcd w t) (exec root d exec user d) ( ) 10 spec domain user d (/bin/bash /bin/tcsh) (rwxcd user t rwxd root t rwxcd spool t rxd lib t rxd binary t rwxcd passwd t rxwcd shadow t rwxcd dev t rxd config t rwxcd w t) (exec root d) ( ) 11 spec domain ftpd d (/usr/sbin/in.ftpd) (rwcd ftpd t rd user t rd root t rxd lib t r passwd t r shadow t rwcd dev t rd config t rdx ftpd xt rwcd w t d sppol t) () (14 root d 17 root d) 12 assign -u /home user t 13 assign -u /tmp spool t 14 assign -u /var spool t 15 assign -u /dev dev t 16 assign -u /scratch user t 17 assign -r /usr/src/linux user t 18 assign -u /usr/sbin binary t 19 assign -e /usr/sbin/in.ftpd ftpd xt 20 assign -r /home/ftp/bin ftpd xt 21 assign -e /var/run/ftp.pids-all ftpd t Figure 3.2: Sample DTE policy file 3.4 Towards a DTE Formalism Generalities Since the DTE model is simple and flexible enough it was used in different operating systems especially Unix and SELinux [MMC]. SELinux has been defined in order to create a flexible framework for the Linux kernel that allowed different security extensions to be added to Linux. SELinux differs from standard Linux by the access control attributes used. In standard Linux, the access control attributes of subjects are the real and effective user and group IDs associated with all processes. For objects, the inode of the file contains a set of access mode bits and file user and group IDs. These attributes are replaced in SELinux by a single security context associated with them. A security context has three elements: user, role, and type identifiers. The last element is the most important since it is directly used to attribute the permission. Thus, using these attributes, SELinux implements the DTE approach to define the security policy. [TP97] presents a DTE integration into a µ-kernel. It suggests centralizing all access control decisions in user mode. The µ-kernel uses just a domain abstraction. Later, a work done in [KW03] extends the integration of

59 3.4 Towards a DTE Formalism 45 DTE introducing both domains and types into kernel. [HK01, OBV + 97, WSB + 96] are interested in using DTE in Unix and they present examples of DTE policies expressed in DTEL (DTE Language). It is also important to mention that DTE has inspired the design of SELinux. To use DTE as an approach to control information flow, we propose to formalize the model. For this purpose let us introduce the following formal definitions. Definition 1: (domain) S is a set of all system subjects (active entities). S is divided into equivalence classes. Each class represents a domain D including a set of subjects having the same role in the system. Definition 2: (type) O is a set of all system objects (passive entities). O is divided into equivalence classes. Each class represents a type T including a set of objects having the same integrity properties in the system. In the sequel D denotes the set of different system domains and T denotes the set of different system types. The set of privileges of different domains defined on types is represented by the set DT AM. DDAM denotes different access modes that a domain has on another domain. The type of accesses defined in DTAM and DDAM depends on the system or the organization that we deal with. For example, if the system resources are files and folders these access modes will be: read, write, execute, delete, create,... D = { D 1, D 2,..., D i,..., D n }, n is the number of domains within the system T = { T 1, T 2,..., T j,..., T m }, m is the number of types within the system DTAM = { DTAM 1, DTAM 2,..., DTAM i,..., DTAM k }, k is the number of defined privileges of domains on types. DTAM includes all privileges that can exist on the entries of DDT matrix. DDAM = { DDAM 1, DDAM 2,..., DDAM i,..., DDAM l }, l is the number of defined privileges of domains on domains. It includes all access modes or privileges that domains can have on domains. This set can include the privilege Execute(EP i,j ) which means the privilege of executing the entry point EP i,j or also Transit(D i, D j ) which means the privilege to transit from the domain D i to the domain D j

60 46 An integrated model for access and information flow requirements To define different privileges that a subject can have into a domain we use the predicate Auth(s,d, pr) meaning that the subject s has the privilege pr in the domain d. The set of all privileges of a subject is denoted Priv(s). Then, to define different relations between subjects, domains, objects and types we define the following functions. assign domain: S D, a many-to-many mapping of subjects to domains. A subject can be assigned to more than one domain. However, to ensure security issues, a subject s can act at a specific time on only one domain. This domain is called current domain(s). assign type: O T, a many-to-one mapping of objects to types. The relation associates one type to each object. An object can not have more than one type otherwise it causes an inconsistency when this object is accessed by different subjects. The execution of different entry points of a domain implies changes in the system. So, let us consider the following definition: Definition 3: (Entry Point) An entry point is a program or an activity which can be executed to pass from a domain D s to a domain D d, denoted EP(D s, D d ) or EP s,d. Each domain can have one or several entry points. An entry point implies two rules: 1. subjects passing from D s to D d obtain a set of privileges depending on the entry point they execute, 2. subjects passing from D s to D d loose all their D d privileges. The first rule means that the execution of an entry point defines the set of privileges that subjects will obtain when transiting from a domain D s to a domain D d. These privileges are included into or equal to the set of privileges that D d subjects have. Each domain can have more than one entry point. The execution of these different entry points implies different privilege sets. The second rule means that if a subject leaves a domain it can not return to it only by executing one of its entry points. Let Execute (s, EP(D i, D j )) denotes that the subject s executes the entry point EP(D i, D j ). So, a formal definition of the execution of an entry point can be: Definition 4: (Entry point execution) Let s S, D 1 and D 2 D, priv and priv DTAM, EP(D 1, D 2 ) SEP(D 2 ):

61 3.4 Towards a DTE Formalism 47 Auth (s, D 1, priv) Execute (s, EP(D 1, D 2 )) Auth (s, D 2, priv )!= (priv, priv) Auth (s, D 1, priv) Now let us deal with communications between different domains. SEP (D) denotes the set of entry points of a domain D. A transition between two domains is possible if and only if these three conditions are satisfied: 1. The destination domain D d holds entry points. 2. The source domain D s have an execute access on an entry point of the destination domain. 3. The source domain D s has the transit (Enter) access on the destination domain. This is equivalent to: 1. SEP(D d ) 2. EP s,d SEP(D d ) / Execute(EP s,d ) DDAM s D s, Auth(s, D s, Execute(EP s,d )) Priv(s) 3. s D s, Transit(D s, D d ) DDAM Auth(s, D d, Transit(D s, D d )) Priv(s) Confidence Path Concept Let us suppose the following DDT and DIT: T 1 T 2 T 3 D 1 true false true D 2 false false true D 3 false true false D 1 D 2 D 3 D 1 EP 1,2 D 2 EP 2,1 EP 2,3 D 3 DDT entries, true and false, indicate if the domain has an access to different types or not. DIT entries define the entry points that must be executed to transit from a domain to another. If we consider that a subject s belonging to the domain D 1 wants to access to an object o belonging to T 2, it will refer to the DDT. s has no access to T 2, but consulting DDT and DIT it can find a manner to access to T 2. In fact, D 3 has access to T 2 and s has an entry point allowing it to access to D 2. Also, the DIT presents an entry point from D 2 to D 3. So, to access to o, s must execute EP 1,2 to pass to D 2 then it must execute EP 2,3 to pass to D 3. Being in D 3, s obtains privileges allowing it accessing to o since DDT contains an

62 48 An integrated model for access and information flow requirements entry from D 3 to T 2. This path that s constructs to access to o is called confidence path. The following definition gives a formal definition of confidence path. Definition 5: (confidence path) is a set of entry points <EP i,k, EP k,l,..., EP m,j > which must be executed by a subject s to pass from D i to D j in order to obtain access to an object to which it has not initially the access. Privileges granted through this confidence path are restricted to minimum privileges required to perform the access needed. To better formalize the concept and the use of confidence path, we have resorted to graph theory. In fact, we model the DIT using a graph. The domains defined in the DIT represent the nodes of the graph. The entries of the matrix (different entry points) represent the edges in this graph. So if there is an entry point defined for the domain D j to be accessed from a domain D i then there is a direct edge from D i to D j. Therefore, when the graph is constructed, we use it to determine different possible confidence paths for each domain. The problem of searching different confidence paths is equivalent to an usual problem known as the problem of transitive closure [AJ87]. Thus, if a subject needs an access to a type and he has no direct access to this type (the access is not defined in the DDT) then he refers to its set of confidence paths and checks if one of the final domains (the extremity of a path) of these paths has access to this type. Then it has to execute the set of entry points defined with this confidence path. The execution of these different entry points will define a new set of privileges to this subject thus he will get only the required access to execute his action. This is the least privilege principle defined in security. If there are more than one path which satisfies the access needed, the subject can choose the shorter path, i.e. the path having less entry points to execute. The definition of this concept leads us to the following definition: Definition 6: (Accessing types) s D, t T, s can access to t with a privilege priv if and only if one of these two conditions is satisfied: 1. priv DTAM (D, t, ac) DDT 2. priv DTAM P SCP(D) / (final domain(p), t, priv) DDT DTE Rules The DTE formalism is based on two kinds of rules expressing and interpreting DDT and DIT. These two rules are formally defined in the following.

63 3.4 Towards a DTE Formalism 49 Definition 7: (SR DDT) is a security rule interpreting a DDT entry. It is defined as a 4-uplet : SR DDT = ( rule type, domain, type, privilege) where Rule type belongs to {permission, prohibition}. An instance of this rule can be: SR DDT = (Permission, professor, exam, change) meaning that only professors have privileges to change exams. So, we express a DDT as a set of rules defined according to definition 5. Definition 8:(SR DIT) is a security rule interpreting a DIT entry. It is defined as a 4-uplet: SR DIT = (rule type, domain1, domain2, entry point) where Rule type belongs to {permission, prohibition}. An instance of this rule can be: SR DIT = (Permission, engineering, http d, /usr/bin/httpd) meaning that engineers have permission to pass from engineering domain to http d domain by executing the program /usr/bin/httpd. When transiting to http d, engineers obtain a set of http d privileges defined by the execution of the entry point and they loose all privileges of the source engineering domain. The next section shows how these security rules will be transformed to get rules expressed using the OrBAC model. The meaning of these rules will be preserved. So, since OrBAC rules can not directly express information flow control, we will show how to express it using the entry point notion defined in the DTE model. T 1 : - R e a d - Write - Execute T 2 : - R e a d - Write T 3 : - R e a d D 1 E (2) 2,1 E 2,3 D 3 E (1) 2,1 Type access D 2 E 3,2 Domain interaction Figure 3.3: Sample of a graphic system topology As an example of a DTE policy, let us consider the figure 3.3. It presents a system consisting of three domains D 1, D 2 and D 3. These domains have different

64 50 An integrated model for access and information flow requirements SR DDT SR DIT (Permission, D 1, T 1, Read) (Permission, D 2, D 1, E 2,1 (1)) (Permission, D 1, T 1, Write) (Permission, D 2, D 1, E 2,1 (2)) (Permission, D 1, T 1, Execute) (Permission, D 2, D 3, E 2,3 ) (Permission, D 1, T 2, Read) (Permission, D 3, D 2, E 3,2 ) (Permission, D 1, T 2, Write) (Permission, D 2, T 2, Read) (Permission, D 2, T 2, Write) (Permission, D 3, T 3, Read) Table 3.1: DTE policy corresponding to the system topology. accesses to three object types T1, T2 and T3. Also, there are authorized interactions between them defined through different entry points. We remark that D 1 has two entry points. In the system specification we can suppose that EP 2,1 (1) grants read and execute privileges to D 2 subjects and EP 2,1 (2) grants write privilege to D 2 subjects. Table 3.1 summarizes the DTE policy corresponding to figure 3.3. Thus, we define our DTE security policy as a set of SR DDT and SR DIT rules. This policy satisfies information flow requirements. Our integrated model uses this policy to deal with information flow control. We choose to base our model on the OrBAC model as it is enough expressive and it allows us to integrate our flow control policy using access control rules. OrBAC offers context notion which permits us to define dynamic rules and to express our control flow policy using these rules. 3.5 Access and information flow control convergence In this section, we present our integrated model for access control and information flow requirements. The model is based on OrBAC to express access control and it is enriched with a DTE approach to express information flow control. This convergence allows us to define a single model (our proposed model) to specify security policy of a system. The basic idea of this integration is to make a correspondence between DTE concepts and OrBAC concepts. This correspondence is described in general in table 3.2. The last part of this section will explain and exemplify the model Access control policy OrBAC defines contextual rules which can depend on different contexts. These contexts can be related to conditions or circumstances under which a rule is valid or an activity is performed. If we observe SR DDT and OrBAC rules we can deduce

65 3.5 Access and information flow control convergence 51 DTE OrBAC Organization Domain Role Type View Privilege Activity Entry point Context Table 3.2: DTE and OrBAC concepts correspondence that the former are expressed by the latter using a default context. The default context is expressed in OrBAC as a context which is always true. So rules with such context are always valid. In fact, role, activity and view significance in OrBAC match respectively domain, privilege and type significance in DTE. So, an SR DDT rule can be easily expressed using an OrBAC rule. This is a quite natural result as SR DDT rules are specific access control rules. Further, OrBAC provides means to define more fine access control rules than DDT in DTE can do since it considers different types of contexts. With these different OrBAC contexts we can express various conditions and temporal constraints. Thus, we can specify dynamic and expressive rules which can not be expressed just by using DTE. Also, using prohibitions defined in OrBAC we can explicitly specify accesses implicitly denied in the DDT. That is why we did not choose the DTE formalism to express both access and flow controls, otherwise we get a static integrated model with respect to access control requirements. If the system does not contain several organizations, we can consider for all rules the global organization of the system. This organization will be taken by default and denoted system org. In the sequel, ORG will denote the set of system organizations, R the set of system roles, V the set of system views and A the set of system activities. Using predicates defined in OrBAC and functions defined in previous section we define the following three rules: 1. s S, d D / assign domain(s) = d org ORG, r R / Use(org, r, role) Empower(org, s, r) 2. o O, t T / assign type(o) = t org ORG, v V / Use(org, v, view) Use(org, o, v) 3. p Priv, a A / Use(org, a, activity) Consider(org, p, a) Using these rules, different DDT entries can be transformed into OrBAC rules constituting our security base denoted SB. Thus, we have the following rules:

66 52 An integrated model for access and information flow requirements 1. d D, t T, p Priv, (d, t, p) DDT (permission, system org, d, p, t, default) SB 2. d D, t T, p Priv, (d, t, p) / DDT (prohibition, system org, d, p, t, default) SB Information flow control policy As we have presented, OrBAC is an efficient model to express access control rules. So, it will be very useful if we succeed to express access and flow control using the same model. Our DTE formalism offers SR DIT rules to define information flow control policy. But as we aforementioned, OrBAC is more expressive than DTE to express access control rules. In the sequel, we present our approach to define our integrated model based on OrBAC and using a DTE approach. We suppose, that this policy is closed meaning that what is not permitted is denied and we do not deal with obligations. Prohibitions are used to explicitly specify that an access to a domain is denied. These prohibitions are especially used in mixed policies where prohibitions and permissions must be explicitly expressed. Based on an OrBAC rule, SR DIT [SR DIT = (rule type, domain1, domain2, entry point)] can be seen as a particular OrBAC rule. This rule must express the transition between different domains and must introduce entry point control in order to preserve secure information flow and apply DTE principles. Therefore, to consider this particular rule we make the following hypotheses: 1. the source domain is considered a role in the OrBAC rule (we have already said that the two notions have equivalent meaning) 2. the destination domain is considered a view in the OrBAC rule 3. the transition between two domains can be expressed as an OrBAC activity since the basic goal of this specific rule is to handle interactions between domains. So, we define the OrBAC Enter activity 4. the entry point defines the manner to enter a domain. This is modeled as a condition of rule validation. Therefore, an entry point can be defined as a specific context in an OrBAC rule denoted through(e i,j ) where E i,j is an entry point. This context specifies that the rule is valid only through E i,j execution. Thus, a rule that specifies how to control transition between domains D 1 and D 2 in a given organization org, is expressed as follows: SR (permission, org, D 1, Enter,

67 3.5 Access and information flow control convergence 53 D 2, through(e 1,2 )). These flow control rules can be enriched with other OrBAC contexts. Indeed, the through(e i,j ) context can be used in conjunction with different OrBAC contexts, for example temporal contexts, to express more restrictive or conditioned flow control. Also, We recall that a transition from a domain D 1 to a domain D 2 is possible only if there is the corresponding rule in the policy. To make the control stronger, we use prohibitions. By default if an access is not permitted it is denied since the policy is close. But if we need to explicitly express these prohibitions, prohibitions can clearly be defined under a default context as follows: SR (prohibition, org, D 1, Enter, D 2, default). So the interaction between two domains is allowed only if there is a corresponding permission. Such transitions between domains correspond, in our integrated formalism access control/flow control, to a context change. Since a transition to another domain corresponds to the activation of a new context, new rules will be activated. These rules are those for which this context is valid. The activation of these rules implies the change of privileges for subjects who have executed these transitions. This dynamic management of the security policy and the closed policy hypothesis guarantee the loss of source domain privileges during transition. New granted privileges are defined according to the executed entry point. We notice that this policy is defined by and within the same organization. So, this organization is responsible for the security of the workflow execution. If we are in the case of an inter-organizational workflow, this policy has to be enforced but this is not sufficient since this policy does not deal with possible exchanges between different organizations. The management of this case will be treated in details in chapter 5. We will notice that the entity organization is very useful to control the flow in the inter-organizational environment Example To exemplify our model, let us reconsider the figure 3.2. Using our integrated model, line 9 of figure 3.2 is expressed as the following rules set. We suppose that we are in a Unix system organization. 1. (permission, Unix, login d, rxd, root t,default) 2. (permission, Unix, login d, rwxcd, spool t,default) 3. (permission, Unix, login d, rxd, lib t,default) 4. (permission, Unix, login d, rxd, binary t,default) 5. (permission, Unix, login d, rwxcd, passwd t,default) 6. (permission, Unix, login d, rxwcd, shadow t,default)

68 54 An integrated model for access and information flow requirements 7. (permission, Unix, login d, rwxcd, dev t,default) 8. (permission, Unix, login d, rxwd, config t,default) 9. (permission, Unix, login d, rwxcd, w t,default) 10. (permission, Unix, login d, Enter, root d, through(exec())) 11. (permission, Unix, login d, Enter, user d, through(exec())) The rules 1-9 express the access control policy. Rules 10 and 11 handle interactions between login d and root d, user d respectively. This rule set represents the security policy corresponding to line 9 of the first example in figure 3.2. This policy is based on the OrBAC rules enriched with DTE. It is expressed using only one form of rules. If we consider for instance the first rule, rxd indicates the activity allowed by this rule. Actually, rxd corresponds to three privilege activities: read (r), execute (x) and destroy (d). Thus, this global rule corresponds to three primitive rules in the policy. For the two last rules, the activity field contains Enter which specifies permitted transitions between domains corresponding to flow control requirements. In this example we use the default context when expressing access control rules. This context implies no conditions on the activity execution. Such choice is done to simplify the example. Other contexts, like temporal contexts, could be used in conjunction to the default context or to the through context. The through context is used in flow control rules to control how to enter corresponding domains. A transition into root d and user d domains is released when executing exec() which activates one of the entry points defined for root d and user d respectively: (/bin/bash, /sbin/init, /bin/su) or (/bin/bash, /bin/tcsh). These entry points define privileges granted to login d subjects migrating to root d or user d. Different domains used here are specified in definition 1 of section 3.4. We notice that in this example login d is used as a role in access control rules and root d and user d are used as views in information flow control rules. But, they can be used as domains in other access control rules. According to this policy, login d has no access to the type user t. If a login d s subject requires an access to objects of this type, it must transit to root d or user d which have access to this type (see figure 3.2, lines 8 and 10). So, our integrated model ensures the concept of confidence path defined in the DTE formalism (see definition 4 of section 3.4.2). 3.6 Conclusion In this chapter, we have presented an integrated security model that to take into account information flow and access controls. The security policy is based on OrBAC rules which integrate flow control using a DTE approach. OrBAC is an adequate

69 3.6 Conclusion 55 choice since it permits us to define contextual and dynamic rules. Also, it is enough expressive to integrate information flow control. The organization concept of the OrBAC model allows us to express confinement. Our approach solves weaknesses present in previous approaches based on MLS and RBAC models. These works are presented in details in section of chapter 2. We recall that the main problem that these works are based on an incorrect mapping between RBAC concepts and MLS concepts. Besides, these works do not express a consistent policy which can be used in both access and information flows controls. In this chapter, we have considered information flow control internal to a single organization. In chapter 5, the inter-organizational case will be considered. The specification of the policy is more complex but it is based on similar concepts and the same basic idea. The confinement principle that the organization entity expresses will be very useful to define the inter-organization policy. This policy has to supervise inter-organization flows. Indeed, organizations must exchange flows to have knowledge of what is happening globally in the system. These flows have to be managed in order to keep a secure execution environment of processes. In the next chapter 4, we show how to apply our integrated model to Workflow Management Systems (WFMS). This is a critical issue since these systems present very important security requirements. In fact, they include multi user requirements, inter-dependent execution and dynamic evolution. We shall show in the following chapters how these different security requirements can be expressed and managed in WFMS environments.

70

71 Chapter 4 Modeling WFMS and Specifying WFMS Security Policy 4.1 Introduction WFMS are based on representing processes as workflows. A workflow representation implies that tasks composing it are interdependent and are communicating control information and data to each other. For example, let us consider a workflow composed of tasks T 1, T 2 and T 3 which must be executed in a sequential order. If we suppose that these three tasks act on the same documents, the access to these documents must be controlled according to the execution order of tasks. In other words, access control must be synchronized with workflow execution progression. In addition, the execution of a task is related to the execution of precedent tasks. So, a workflow specification must be correlatively defined with a security policy. Several proposals [AAH98, AH96, HA99, HK99, BFA99] tried to address this problem and proposed different access control models to manage security in WFMS. These proposals consist generally in the two following parts: 1. Specifying the global workflow security policy 2. Defining a centralized management procedure that controls the execution of the workflow so that it remains compatible with its associated security policy Since these approaches are generally based on the RBAC model [San96] which only provides means to specify static security requirements, they present some limitations that have been detailed in section 2.7 of chapter 2. These works consider that a workflow is a set of sequential tasks. This assumption represents an important restriction. A workflow can actually present different execution modes. If these

72 58 Modeling WFMS and Specifying WFMS Security Policy execution modes have not to been taken into account when executing the workflow, the functional aspect of the workflow may not be respected. Besides many constraint types can be associated with the workflow specification. The violation of these constraints is not permitted. Otherwise the security of the workflow execution will be affected. In this chapter, we suggest a different approach to remedy to weaknesses of previous works. The global security policy associated with the workflow execution is specified using the OrBAC model [KBB + 03]. The OrBAC model provides means to define dynamic and contextual security requirements. For this purpose, this model defines two useful notions. The first notion is the organization which can be seen as an organized group of active entities. Workflow tasks may be executed in the same or different organizations. If they are executed within the same organization, the policy has to manage security in this organization. The notion becomes more useful if workflow tasks are executed in independent organizations. In this case, flows between different organizations must be controlled. The second useful notion defined in OrBAC is the context. A context is used to express permissions or prohibitions that apply in specific circumstances. Each context has a name and its definition depends on the organization [CM03b]. Therefore, the term context corresponds to any constraint or extra conditions that join an expression of a rule in the access control policy. OrBAC classifies contexts according to their type. A provisional context depends on previous actions the subject has performed in the system. In other words, it corresponds to a history of execution. Provisional contexts are very interesting in the domain of WFMS since the execution of a task depends on the execution history of precedent tasks. Also, it permits the definition of a dynamic security policy according to contexts, a very useful requirement in WFMS. Another relevant context in OrBAC is temporal context. This context permits defining temporal constraints and expressing dynamic temporal rules. This context is as interesting as provisional context in WFMS domain. In this chapter, using notions of organization and context already defined in OrBAC, we present a Petri net based model for modelling workflow applications. Then, we use the integrated model defined in chapter 3 to specify a security policy that we associate with the Petri net model in order to define a secure execution environment. Afterwards, we show how to manage this security policy to control the workflow execution in a distributed manner. For this purpose, we define an algorithm to generate the local security policy associated with the execution of each task that composes the workflow. The Petri net based model and the global policy are provided as inputs of this algorithm, a dynamic policy is its output. Our approach remedies to the static and centralized restrictions of models already proposed. Another part of this work concerns the workflow satisfiability problem. Such a problem can be defined as follows: Having a set of constraints associated with

73 4.2 Generalities About Petri Nets 59 the workflow, can this workflow be executed and finished using a specific system configuration?. We are interested in studying the complexity of such a problem. For this reason, we divide the problem into three parts. First, we study the complexity of checking if a constraint set is consistent. This problem has a polynomial complexity. Second, when the set of constraints is consistent, we study the complexity of finding a valid assignment of users to different tasks which satisfies all constraints. We show that it is a NP-complete problem. Finally, we suppose that we have a workflow instantiation and a set of consistent constraints and we study the complexity of checking if this assignment satisfies or not all constraints. We show that this problem has a polynomial complexity. This problem was the topic of [WL07], but in this work, the problem is not very well exposed. Authors do not deal with the consistency of the set of constraints. The work done in this chapter was published in [ACBC08a, ACBC08c]. The chapter is organized as follows. Section 4.2 introduces some generalities about Petri nets since we use them to define our model. Then, section 4.3 presents different constraints that can be specified with the definition of a workflow and their classification. This classification provides means to specify fine-grained execution modes between tasks using Allen s temporal intervals [JAM93]. Section 4.4 defines the Petri net based model that we use to represent workflows. This model is then exemplified. In section 4.5 we introduce the security policy that we associate with the model. This security policy is based on the integrated model presented in the previous chapter. It gathers a general security policy and a coordination security policy to define the access control and it deals with information flow control. Section 4.6 addresses the issue of distributed workflow execution and defines an algorithm to generate the local policies required to execute the workflow in a secure distributed way. It also discusses the algorithm through an example. Section 4.7 studies the complexity of the workflow satisfiability problem. It shows that this problem is NPcomplete. Finally, section 4.8 discusses our contribution and concludes the chapter. 4.2 Generalities About Petri Nets A workflow process is generally modelled as a set of tasks connected by vertices from one task to the task which follows in the execution order. Tasks executed in parallel can be also represented in the workflow. Conditions that can be related to the execution of tasks are represented by vertices. Also, vertices contain information which are exchanged between two successive tasks. Our WFMS model is based on Petri nets [DA92] which provide an expressive formalism to represent synchronous activities. With the graphic representation that they offer, they are considered simple and easy to understand. In addition, they have a mathematical foundation which provides means to formally analyze obtained

74 60 Modeling WFMS and Specifying WFMS Security Policy Figure 4.1: Example of a Petri net models. Thus, Petri nets allow a flexible transition from the conceptual level to the implementation of test, where the system can be simulated and validated before proceeding to a detailed conception and implementation. A Petri net is a bipartite directed graph representation based on two types of nodes called places (represented by circles) and transitions (represented by bars). The edges of the graph can go either from places to transitions or from transitions to places. In these graphs tokens are used to mark places. Also, weights can be assigned to edges to indicate the number of tokens to be moved if a transition is fired. In our model we will assign to different edges the type of the token to be placed in the next place once the transitions is enabled. An example of a Petri net is presented in figure 4.1. Definition 9: a Petri net is defined as a 5-tuple, PN = (P, T, F, W, M 0 ), where: P is a finite set of places, T is a finite set of transitions, F (P T) (T P): a set of vertices from places to transitions and from transitions to places, W : F {1, 2, 3,...}: a weight function, it defines weights assigned to different vertices, M 0 : P {0, 1, 2,...}: the initial marking, it describes initial place contents.

75 4.2 Generalities About Petri Nets 61 We use M(p) to denote the marking of the place p, i.e. the number of tokens of place p. A vertice from a place p to a transition t is denoted f(p, t) and a vertice from a transition t to a place p is denoted f(t, p). Each place can have one or more input and output transitions. The initial places do not have input transitions and the final places do not have output transitions. Identically, transitions have a set of input and output places. these sets are defined in the following definition: Definition 10: Given a Petri net, the input and the output set of transitions for each place p i are defined as, the set of input transitions of p i, denoted p i = {t j / f(t j, p i ) F} the set of output transitions of p i, denoted p i = {t j / f(p i, t j ) F} and the input and the output set of places for each transition t i are defined as, the set of input places of t i, denoted t i = {p j / f(p j, t i ) F} the set of output places of t i, denoted t i = {p j / f(t i, p j ) F} A Petri net evolves when transitions fire. A transition must be enabled to fire. An enabled transition must have at least one token in each place of its input set of places. When a transition fires, the marking of the Petri net changes. Thus, a token is removed from each place of the input set t i and a token is placed in each place of the output set t i. This is in the case where edges are associated to weight 1. The number of tokens to be removed and placed depends on the weight associated with the edges of the fired transition. At a specific time only one transition can fire even if there are many transitions that are enabled to fire. This can be formally expressed as follows: Definition 11: 1. A transition t i is said to be enabled if p j t i, (M(p j )>0). An enabled transition may fire. 2. Firing a transition t i results in a new marking M as follows: p j t i, and p k t i, m (p j ) = m(p j ) - 1 m (p k ) = m(p k ) + 1 To exemplify this process we consider the figure 4.2 which represents a Petri net. We notice that at the initial state both places p 1 and p 2 are marked. This configuration lets transitions t 1 and t 2 be enabled. So, two cases are possible, either

76 62 Modeling WFMS and Specifying WFMS Security Policy Figure 4.2: Petri net marking t 1 or t 2 can fire. These two possible cases are represented respectively in figure 4.2 (b) and (c). Definition 12: In a synchronized Petri net, with each transition is associated an event and the release of the transition will happen (1) if the transition is valid, (2) when the event occurs. Definition 13: a P-temporized Petri net is a couple <R, Tempo> where (1) R is a marked Petri net and, (2) Tempo is an application from the set of places to the set of positive and rational numbers. Tempo(P i ) = d i : temporisation associated with P i. Definition 14: an interpreted Petri net has the following three characteristics: (1) It is synchronized, (2) It is P-temporized, (3) It contains an operative part where the state is defined by a set of variables V. This state is modified by operations Op which are assigned to places. It determines the truth value of conditions (predicates) C which are associated with transitions. Definition 15: a coloured Petri net assigns colours to marks. So a coloured Petri net differs from a general Petri net by the addition of a set of colours. The model that we suggest uses a combination of interpreted and coloured Petri nets. This choice is motivated by the requirements of processes we want to represent. In fact, choosing interpreted Petri nets is related to conditions which can be associated with process execution. Therefore, we assign operations to different tasks. So, we need an operative part in the Petri net representation. On the other hand, the choice of coloured Petri net is done to clarify the process execution. In

77 4.3 WFMS Constraints Classification and Consistency 63 this case, each colour indicates a new process execution. A new execution of the workflow is defined using a new colour. 4.3 WFMS Constraints Classification and Consistency The workflow specification is generally defined correlatively with a set of constraints. These constraints can be applied either to different workflow tasks or to different users and roles. In this section we show how we classify different constraints that have to be ensured during the execution of the workflow. The violation of one of these constraints can affect not only the functional aspect of the workflow but also its security aspect. The set of different constraints can be divided into two classes: the set of static constraints and the set of dynamic constraints Static constraints This set includes constraints which are associated with subjects that are involved in the workflow execution. During the phase of assignment of roles and users to different tasks, these constraints can be checked and validated. So, this assignment has to be consistent with these constraints. Essentially, this set contains: 1. Static Separation of Duty (SSoD): the separation of duty is a very important principle in security. It consists in separating the execution of different activities within a system. In WFMS, this principle consists in assigning different roles or users to different workflow tasks. So, a subject can not be assigned to two exclusive roles in order to execute two different tasks. SSoD are the set of separation of duty constraints that can be evaluated during the specification of the workflow. The assignment must be compatible with the SSoD constraints initially defined. for example if we consider the following two tasks: Initiate a mission Validate a mission We can notice that these two tasks must obligatory be executed by different users and even by different roles. To define these constraints, we define these two predicates: Different roles (T i, T j ): states that the task T i and the task T j must be achieved by different roles. Different subjects (T i, T j ): states that the task T i and the task T j must be achieved by different subjects.

78 64 Modeling WFMS and Specifying WFMS Security Policy 2. Binding of Duty (SBoD): the binding of duty is the opposite of SoD principle. This constraint stipulates that a set of tasks has to be executed by the same role or user. As an example, the following two tasks have to be executed by the same subject: Apply for a loan Sign the demand of loan To define these constraints, we define the two following predicates: Same role (T i, T j ): states that the task T i and the task T j must be achieved by the same role. Same subject (T i, T j ): states that the task T i and the task T j must be achieved by the same subject. 3. Assignment constraints: this type of constraints includes constraints that directly assign a specific role or subject to achieve a specific task of the workflow. To define these constraints we use the following predicates: must execute R (R i, T j ): states that the task T j must be executed by the role R i. must execute S (S i, T j ): states that the task T j must be executed by the subject S i. The negation of these predicates can be also used to define constraints on tasks and subjects executing these tasks. These constraints can generally be satisfied when assigning users to roles and tasks. If the assignment is made during the execution of the workflow, i.e. we assign the user just when the task has to be achieved, this can lead to an impossible satisfaction of all constraints. To clarify this idea lets us consider the following example. We suppose that we have a workflow consisting of two tasks T 1 and T 2 to be executed sequentially and two subjects Alice and Bob. We define these two constraints on the workflow tasks: 1. Same subject (T 1, T 2 ) 2. must execute S (Alice, T 2 ) We suppose that we assign the subject Bob to the task T 1. Only the first constraint applies the task T 1. So the second constraint is not taken into account during the first assignment. Now, when task T 1 ends, we have to assign a user to execute the task T 2. We notice that the two constraints applies to this task. Since the task T 1

79 4.3 WFMS Constraints Classification and Consistency 65 is executed by the subject Bob, the task T 2 has to be executed by the same subject according to the first constraint. However, the second constraint states that the task T 2 has to be executed by the subject Alice. Thus, we conclude that in this case the set of constraint is violated. So, through this example we show that a dynamic assignment of users to different roles and tasks can affect the consistency of the constraint base. Also, we have to take care about the consistency of the constraint base at each change which may happen in the workflow. This change can concern tasks of the workflow or also the assignment initially defined for the execution of the workflow Dynamic constraints The class of dynamic constraints includes different constraints that can be evaluated only when the workflow starts its execution. This class includes the following constraints types. We notice that temporal constraints are very important within WFMS since different workflow tasks depend on each other and the order of tasks execution is critical especially when tasks act on the same resources. 1. Dynamic Separation of Duty (DSoD): compared to SSoD, DSoD offers more flexibility to the system. In fact, DSoD states that a subject can be assigned to two exclusive roles to execute two tasks but this subject can not activate these two roles at the same time. The role activation is not explicitly defined in the OrBAC model. However, the activation of a role can be considered as a transition from a specific role to another role. As we have specified in chapter 3, this transition implies that the subject must loose all the privileges of the first role and he will be offered a new set of privileges when transiting to the new role. Thus, the DSoD is ensured since privileges related to two roles are not activated at the same time. 2. History constraints: these constraints are based on the history of execution of previous tasks. We define the following predicates: execute S (T j, S i ): states that the subject S j has executed the task T j execute R (T j, R i ): states that the role R j has executed the task T j An example of history constraint can be defined as follows: execute S (T j, S i ) must execute S (S k, T l ). The constraint means that if the task T j has been executed by S i then T l has to be executed by S k. We notice that this constraint can be evaluated only when T j is executed.

80 66 Modeling WFMS and Specifying WFMS Security Policy 3. Execution constraints: this type of constraints acts on workflow tasks. Indeed, these constraints define conditions and relations between different task executions. They relate the execution of one task to the execution or the result of execution of another task. For example, we can define a constraint saying that if task T i aborts then the task T j must abort or if T i successes then the task T j must success. We notice that these constraints relate the execution of a task to the failure or the success of another task. The result of a task execution can be a success, a fail or an abort. If we consider these three actions as predicates, an execution constraint stating that if T i execution fails then T j must abort can be expressed as follows: fail(t i ) abort(t j ). 4. Temporal constraints: In our WFMS model, we do not want to restrict execution modes of two tasks to sequential and parallel execution. Instead we take our inspiration from [JAM93] which defines a complete set of execution modes of two tasks having each an execution time interval. So, let T i and T j be two tasks having respectively two execution intervals I 1 and I 2. There is a basic set of mutually exclusive primitive relations that can hold between temporal intervals [JAM93]. We recall these relationships which can exist between the two intervals and classify them in two classes describing sequential and parallel execution. Sequential execution Before(I 1, I 2 ): time interval I 1 is before interval I 2, and they do not overlap; Meets(I 1, I 2 ): this is a particular case of Before. Interval I 1 is before interval I 2, but there is no interval between them, i.e., I 1 ends when I 2 starts. Parallel execution Equal(I 1, I 2 ): I 1 and I 2 are the same interval; Starts(I 1, I 2 ): time interval I 1 shares the same beginning as I 2, but ends before I 2 ends; Finishes(I 1, I 2 ): time interval I 1 shares the same end as I 2, but begins after I 2 begins; During(I 1, I 2 ): time interval I 1 is fully contained within I 2 ;

81 4.3 WFMS Constraints Classification and Consistency 67 Symbol (T i, T j ) (T i, T j ) (T i, T j ) (T i, T j ) ±(T i, T j ) Temporal constraint T i must begin after T j end T i must begin with T j T i must begin after T j start T i must end with T j T i must end before T j Table 4.1: Different temporal constraints between two tasks. Overlap(I 1, I 2 ): time interval I 1 starts before I 2 and they overlap. In the case of WFMS, tasks do not have necessarily an associated execution interval. So, we go beyond this limitation and we only consider the order relation that can exist between two tasks of the workflow. We summarize different cases presented above into five atomic temporal constraints. These constraints are defined in table 4.1. Using combination of these different cases we can reconstruct the different interval relationships presented in [JAM93]. To each constraint, we assign a symbol to represent it Constraints consistency The respect of different workflow constraints is needed when executing the workflow. However, we must be sure that the constraint base defined with the workflow specification is consistent. The existence of contradictory constraints can affect the consistency of this set. In this section, we give three main characteristics to respect when defining the workflow constraint base. 1. Constraints transitivity: two constraints can be transitive if they imply the same relation between all their elements. For example, if we have two constraints saying same subject(t i, T j ) and same subject(t j, T k ), then we can conclude the constraint same subject(t i, T k ). Transitivity in a constraint base can not be trivial when the number of constraints is large and so it can hide some contradictions in the whole definition of the constraint base. As a matter of fact, constraints that can be deduced from the transitivity of constraints can be in contradiction with other constraints belonging to the base. 2. Constraints redundancy: redundancy can make the constraint base more complex and larger. For example if we consider these three constraints: (1) same role(t i, T j ) (2) must execute R(R i, T j ) and (3) must execute R(R i, T i ),

82 68 Modeling WFMS and Specifying WFMS Security Policy we can notice that the third constraint is not necessary in the constraint base. It just makes the base larger. 3. Conflicting constraints: we have to be sure that the set of constraints does not contain contradictory constraints. If we suppose these three constraints (1) same subject(t i, T j ), (2) same subject(t j, T k ), (3) different subject(t i, T k ), we can notice that these constraints are not consistent. Indeed, the two first constraints implies the constraint same subject(t i, T k ) which is contradictory with the third constraint. 4.4 Modeling WFMS WFMS Petri Net Model In this section, we use the OrBAC concepts to define our WFMS Petri net model. It is based on a formal representation of workflows using Petri nets. Our modelling is constructed in terms of roles, views, activities, organizations and contexts. Roles, views and activities notions are used as they are defined in OrBAC. These concepts are defined within the formalism of Petri nets to express functional aspects of a business process. Then, this framework will allow us to define our security policy. So, roles, views and activities defined in OrBAC are respectively interpreted within the context of our model: 1. R: a finite set of roles defined in the process 2. V: a finite set of views used during the execution of the process 3. A: a finite set of activities associated with places in the Petri net. An activity can be an atomic operation or a composed operation. A place can be validated only if all operations associated with this place are executed. We also use the concepts of context and organization suggested in OrBAC. The concept of organization is associated with places. Different operations defined in relation with a place are executed within an organization. Different places can belong to the same or to different organizations. Also, a hierarchy may exist between different organizations. Managing these different organizations can be either centralized or distributed. In the first centralized case, a root organization must manage different functionalities of different other organizations which can be sub organizations of the root organization. So, it is responsible for supervising the correct execution of the whole workflow. In the second distributed case, each organization defines and manipulates its proper scope and so supervises only operations belonging to him. In this case, information can be exchanged between the set of organizations to be able to control what is happening globally in the system.

83 4.4 Modeling WFMS 69 The notion of contexts is also associated with places. As suggested in [CM03b], OrBAC defines several categories of contexts. These different context types allow us introducing the set of constraints that can be associated with the workflow specification. For example, the Prerequisite context aims to restrict or extend privileges granted to a role depending on some conditions. So, this context category is useful in WFMS to specify constraints associated with the workflow process execution. For instance, if P 1 and P 2 are two places of a workflow, we can associate the place P 2 with a context same subject(p 1, P 2 ) to constrain subjects who are executing activities assigned to place P 1 and P 2 to be equal. We notice here that places P 1 and P 2 have replaced tasks in the predicate same subject. This is coming from the associations of different activities of the workflow to different places of the Petri net. Also, the Provisional context, that depends on previous actions the subject has performed in the system, is relevant for WFMS. In fact, in a workflow execution, a task execution depends on the execution history of precedent tasks. Hence, with each place we can associate a context. It represents the context of execution of operations associated with this place. It consists of two parameters: a color and a provisional context called execution context. So, let Cont i be the context of the place P i. Cont i = (colour, execution context): the colour is used to identify the instance of process execution. The second parameter defines requirements associated with P i execution. It specifies precedent tasks that must be executed before the execution of operations associated with P i. This context includes not only history constraints but also temporal constraints. As a matter of fact, it represents places according to their execution order using definitions of execution modes done in sub section Different other constraints may be also integrated in the context of the place. Different associations that have to be enforced between constraints and OrBAC context will be further explained in section 4.5 when the WFMS security rule will be specified. However, in our model, we suppose that, when defining the global security of the WFMS, the execution context of each place is not explicitly defined because it can be derived from the Petri net representing the workflow. The global policy is defined independently of the workflow scheduling. So, it considers an abstraction of places. Initially, the execution context of a place is only containing the place itself. Then it will be instantiated to take into account the different constraints associated with the workflow execution. In particular, we shall show how to integrate different execution modes in the security policy associated with the workflow execution. Finally, to validate the functionalities of our Petri net model, we define a specific type of tokens. This token is responsible for the evolution of the Petri net marking and so control the workflow execution. In our model, a token has more semantics than that defined for a classic Petri net. This token is enriched with OrBAC concept

84 70 Modeling WFMS and Specifying WFMS Security Policy semantics. A token is a triple <r, v, cont(p)>. For a token <r i, v i, cont(p i )> placed in a place P i, the first parameter (r i ) indicates the role eligible to execute the operation associated with P i. The second parameter (v i ) designates the view which will be used in the operation associated with P i. The last parameter (cont(p i )) represents the context of the place P i. For example, let us reconsider figure 4.1 and suppose that the transition T 1 is enabled. When this transitions fires, a token <r 1, v 1, cont(p 1 )> will be removed from the place P 1 and a token <r 2, v 2, cont(p 2 )> will be placed in the place P 2. This implies the following steps: 1. The operations associated with place P 1 have been executed by the role r 1, using v 1, under the context cont(p 1 ) and using the required permission. 2. Once the token is removed, the execution ends and r 1 has no access on v 1 and on operations associated with P When the token is placed in P 2, all operations associated with P 2 have to be executed by subjects assigned to the role r 2, if it has the required permission, using v 2 and under the context cont(p 2 ) Example To illustrate our model, we apply it to an application of initiating a mission for an enterprise employee. This application will need to reserve a fly, a hotel and a car. We represent the workflow of the application in figure 4.3. First, we introduce essential elements to define the Petri net model that we propose to represent the application of initiating a mission. Then, the model is represented in figure 4.4. In this model, we suppose that: All transitions are synchronized on the event e. All places have an instantaneous execution duration except places P 26, P 27 and P 28 which have respectively a duration d1, d2 and d3. The application defines three conditions when executing the process. These conditions, when used on a transition, imply the choice of the next place and so the next operation. They are defined as follows: C1: the choice is authorized C2: the overtaking is validated C3: there is no overtaking if criteria are changed Roles defined in the model :

85 4.4 Modeling WFMS 71 Figure 4.3: Workflow of the travel application

86 72 Modeling WFMS and Specifying WFMS Security Policy r 1 : responsible of the agency of the travel application r 2 : traveler r 3 : checker r 4 : responsible for the budgetary center r 5 : responsible for the agency of car rental r 6 : agent of the hotel r 7 : responsible for the airline Types of used objects : O1 : profile slip O2 : demand of travel O3 : slip of mission O4 : list of possibilities for booking a car O5 : list of possibilities for booking a room O6 : list of possibilities for booking a flight O7 : pre-reservation O8 : reservation O9 : demand of validation O10 : payment slip O11 : information mail Operations associated to different places, each operation Op i is associated with a place P i : Op1 : create a mission. <r2, o3, c> Op2 : submit the demand of travel. <r2, o2, c> Op3 : demand of car rental depending on criteria. <r1, o2, c> Op4 : demand of room reservation depending on criteria. <r1, o2, c> Op5 : demand of flight reservation depending on criteria. <r1, o2, c> Op6 : provide a list of possibilities for the car rental to the traveler. <r5, o4, c> Op7 : choose a possibility. <r2, o4, c> Op8 : demand of validation of the overtaking. <r1, o9, c> Op9 : pre-reserve a car. <r1, o7, c>

87 4.4 Modeling WFMS 73 Op10 : provide a new list of possibilities for the car rental to the traveler. <r1, o4, c> Op11 : change criteria. <r2, o2, c> Op12 : provide a list of possibilities for the room reservation to the traveler. <r6, o5, c> Op13 : choose a possibility. <r2, o5, c> OP14 : pre-reserve a room. <r1, o7, c> Op15 : demand overtaking validation. <r1, o9, c> Op16 : provide a new list of possibilities for the room reservation to the traveler. <r1, o5, c> Op17 : choose a possibility. <r2, o2, c> Op18 : provide a list of possibilities for the flight to the traveler. <r7, o6, c> Op19 : choose a possibility. <r2, o6, c> Op20 : pre-reserve a flight. <r1, o7, c> Op21 : demand overtaking validation. <r1, o9, c> Op22 : provide a new list of possibilities for the flight to the traveler. <r1, o6, c> Op23 : change criteria. <r2, o2, c> Op24 : demand mission validation. <r1, o3, c> Op25 : validate the mission. <r3, o3, c> Op26 : rent a car. <r1, o8, c> Op27 : reserve a room. <r1, o8, c> Op28 : book a flight. <r1, o8, c> Op29 : inform the traveler. <r1, o11, c> Op30 : start the payment process. <r1, o10, c> In front of each operation we represent the token that will be needed to execute each of these operations. These tokens are shown on the figures 4.4, 4.5, 4.6 and 4.7 on different edges of the Petri net. Using these different elements, we represent the initial model associated with the application. This representation (figure 4.4) introduces the model before the execution of the process. So, contexts contain just places with which they are associated. With the execution progression of the process, they are changed dynamically. We notice that the Petri net model defines different execution modes. Parallelism is represented at transition T 2. If this transition is

88 74 Modeling WFMS and Specifying WFMS Security Policy Figure 4.4: Modeling for the travel application

89 4.4 Modeling WFMS 75 Figure 4.5: Modeling for the SPN1

90 76 Modeling WFMS and Specifying WFMS Security Policy Figure 4.6: Modeling for the SPN2

91 4.4 Modeling WFMS 77 Figure 4.7: Modeling for the SPN3

92 78 Modeling WFMS and Specifying WFMS Security Policy enabled, when it fires, three tokens (<r1, o2, c>) are placed respectively in places P 3, P 4 and P 5. Tasks associated with these places have a parallel execution. We notice that there are three sub Petri nets that have to be executed in parallel: SPN1, SPN2 and SPN3. These sub Petri nets are detailed respectively in figures 4.5, 4.6 and 4.7. The end of execution of these different sub Petri nets is synchronized. This synchronization is modeled by transition T 30. So, this transition can be enabled only if all operations associated with the SPN1, SPN2 and SPN3 end. When this transition fires, a token <r1, o3, c> has to be placed in P 24. The Petri net is temporized as we have associated durations to places P 26, P 27 and P 28. The example shows also that the colour c used in the token is used to specify the instance of the process. So, if we have to start a new instance, this colour is changed. We can notice in SPN1 that if the condition C3 is not satisfied and the transition T 9 is enabled then, when T 9 fires, a token <r2, o3, c > is placed in P1. This transition allows us to re-initiate the process and so a new instance of the workflow is started. This new instance is distinguished from the first one by its new colour c. The same thing can be noticed in SPN2 and SPN3 with transitions T 18 and T 27. When the process starts its execution, contexts change with it. These changes are explained in the algorithm proposed in section This Petri net modelling is the first input of our algorithm presented in the sequel. The second input will be the security policy that we specify in the following section. So, a system manager must define a Petri net representation of its WFMS application according to our proposed modeling approach. 4.5 Specifying WFMS global security policy Once we define the Petri net modelling of our WFMS application, we define the security policy to be applied to the model. To ensure a secure execution environment of the workflow, we must take into account three aspects: 1. We have to control access to objects during tasks execution. 2. We have to ensure and enforce different execution modes defined in the workflow process without violating different constraints. 3. We have to deal with information flow control. These aspects could make our security policy more useful and increase assurance that it is correctly specified. So a system manager must have as inputs, its Petri net modelling and the policy associated with it in order to generate a dynamic policy that is updated while the workflow execution is progressing. So, to express and specify our security policy which will control the workflow execution, we will use our

93 4.5 Specifying WFMS global security policy 79 integrated model presented in the previous chapter. We will show that the security policy, based on our integrated model, will contain: (1) rules to define the access control model without violating constraints of the workflow specification, (2) rules to express different temporal modes of different workflow tasks and (3) rules to express information flow control as it is defined in the previous chapter. These rules are based on the OrBAC model enriched to express different workflow requirements Access Control Policy Our access control policy is derived from a general security policy to manage access to different system objects and a coordination security policy to enforce temporal constraints and execution modes of different tasks WFMS General Security Policy Figure 4.8: Applying access and flow control to a Petri net Our general security policy defines access control rules. These rules are expressed using the OrBAC model. So a general security rule is defined as a 6-tuple: security-rule (type, organization, role, activity, view, context). These rules use the specific context defined in our Petri net model (see section 4.4.1). Thus, let us consider the Petri net of figure 4.8. An access control security rule is associated with different places of the Petri net. For example, a security rule defined as a permission granted to a role R 3 within the organization Org 3 to execute an activity A 3 associated with the place P 3 by the same subject that has executed A 1 and must end before A 2 in this Petri net and using a view V 3 will be expressed as follows: security-rule (permission, Org 3, R 3, A 3, V 3, (same subject(a 1, A 3 ),

94 80 Modeling WFMS and Specifying WFMS Security Policy ±(A 2, A 3 ), P 3 )) We have already supposed that our initial execution contexts contain just the place. It is not necessary to explicitly specify the execution context associated with this rule. This execution context will be automatically derived from the workflow description using the algorithm presented in the following section. In this policy we exploit different OrBAC concepts to express different workflow constraints. Expression of workflow constraints using OrBAC concepts: Different constraints defined in section 4.3 have to be taken into account in the security policy. In the sequel we show how they can be expressed in our security policy. SoD: separation of duty can be expressed using predicates defined in the Or- BAC model. Indeed, separated role, separated view and separated activity states respectively the SoD in roles, views and activities. However, this definition is not done in the security rule. The policy administrator has the possibility to introduce these constraints after defining the policy entities or even when these constraints are added to the process. Then, in the actual version of the OrBAC model, these predicates can be used to determine possible conflicts that can exist when defining the security policy. So, the validation of the defined security rules according to these constraints of SoD is taken into account by the MotOrBAC tool [ACCC08], the tool implemented to specify a security policy based on OrBAC. BoD: the binding of duty can be expressed using the prerequisite context. Thus, the security rule expressing a BoD is contextual and its context includes the predicate same subject(t i, T j ) to state that the task T i and the task T j must be executed by the same subject. When instantiating the rule, the constraint have to be taken into account to check if the subject assigned to the role is valid and satisfy the constraint or not. To define that two tasks have to be executed by the same role, we have to define two different rules for each task. The security rule associated with each activity will define the appropriate role authorized to execute the required task. Assignment constraints: these constraints are satisfied when defining security rule by assigning adequate roles and then adequate subjects to appropriate tasks. So, these constraints should be checked before the start of the workflow execution. History constraints: these constraints can be expressed as a provisional

95 4.5 Specifying WFMS global security policy 81 context in OrBAC rules. Thus, these contextual rules will be activated only if the context and so the constraint is valid. Execution constraints: to be satisfied, history constraints need an information about the execution progression of the workflow. In the OrBAC model, as it is defined in the actual version, this type of history information is not provided. Thus, to express and check this type of constraints we have to save the execution result of each task already executed. Then, we can use the provisional context to express the required execution constraint. Temporal constraints: provisional context is defined in order to express this type of constraints. So, the general security rules are contextual rules and in the same rule many contexts can be combined to expression more than one circumstance or condition related to the workflow specification. These rules are defined before the start of the workflow execution. Then, the workflow execution must satisfy to these different constraints since the security policy is contextual and it deals with these different constraints. If one of these constraints will not be satisfied, then the security policy will be violated WFMS Coordination Security Policy The general security policy manages access control but it does not deal with different tasks execution modes in the expression of authorizations. As a matter of fact, the different execution modes can be expressed in the context. These contexts will be generated when the workflow starts its execution. But, to be sure that tasks will be executed in the order specified in the workflow definition we have to define authorizations which can be able to initiate and secure the beginning of another task. For example, if we suppose that we have two tasks T i and T j that must be executed in a parallel way, we must be sure that we have appropriate authorizations allowing this parallel execution. In fact, if T i starts then even if T j has not been started, we have to initiate this task in order to keep the constraint initially defined between these two tasks. Thus, to do so, we are led to use obligations in addition to permissions. Obligations are explicitly used in the OrBAC model as shown in [ERCBC09]. So to complete our access control policy we propose a coordination security policy which ensures a secure environment to execute workflows. This coordination security policy is collateral to our general security policy. This policy controls different temporal constraints presented in section Also, it enforces different task dependencies and so it preserves the correct functional execution of workflows.

96 82 Modeling WFMS and Specifying WFMS Security Policy Coordination policy is based on temporal and provisional contexts. These contexts can be used in conjunction with other contexts or conditions. They depend on the time at which the subject is requesting for an access to an object or a view. With temporal contexts, it should be possible to express that a given action made by a given user on a given object is authorized only during a given time interval. Provisional context allows expressing that a task has to be executed after or before another task execution [CM03b]. To express our coordination contexts, we use predicates defined in the Nomad model [CCBS05]: start(t) ( starting T ), doing(t) ( doing T ) and done(t) ( finishing T ), where T is a task. start(t) indicates exactly the instant of beginning task T. doing(t) indicates instants during T execution. done(t) indicates exactly the instant of finishing task T. To express a conjunction between different contexts and conditions, we use first order logic. Figure 4.9 represents these different predicates for a task T. The task T is represented by the black continuous line. Figure 4.9: Set of task predicates In our case, we consider that these predicates can be used either as specific activities or specific contexts. Considered as activities, start(t) means the activity to start the task T and done(t) means the activity to finish the task T. Our coordination policy is defined as a set of different temporal constraints associated with the different execution modes. We present our coordination policy in table 4.2. This policy makes explicit different temporal constraints presented in section Thus, we associate with each execution mode its coordination security policy to be enforced. For simplicity, we represent these coordination rules using just the activity and the temp context predicates. But these rules are actually defined within an organization, for a specific role and using a specific view. For simplicity, a permission is denoted P and an obligation is denoted O. Also, we use default context to define a context where neither conditions nor constraints on the activity are required. By combining different elementary constraints we can get more complicate contexts. For example, to specify that two tasks T i and T j have to be executed in parallel is defined by combining the two following elementary constraints: (1) T i must start with T j and (2) T i must end with T j.

97 4.5 Specifying WFMS global security policy 83 temporal Associated Policy constraints - P(start(T j ), default) (T i, T j ) - O(start(T i ), done(t j )) - P(start(T i ), default) (T i, T j ) - P(start(T j ), default) - O(start(T i ), start(t j )) - O(start(T j ), start(t i )) - P(start(T i ), default) (T i, T j ) - P(start(T j ), default) - O(done(T i ), done(t j )) - O(done(T j ), done(t i )) - P(start(T j ), default) (T i, T j ) - O(start(T i ), doing(t j )) - P(start(T j ), default) ±(T i, T j ) - O(done(T i ), doing(t j )) Table 4.2: WFMS coordination security policy Information Flow Control Security Policy In the previous chapter we have presented how to express information flow control and access control based on OrBAC rules. These rules are then applied to our Petri net model. As said before, access control is applied to places of the Petri net. By contrast, information flow control is applied to transitions as it is shown in figure 4.8. This idea comes from the role that a transition has in a Petri net. In fact, when a transition fires it implies a transition from one or several places to one or several places. With these places are associated workflow tasks and roles executing these tasks and views used to accomplish the execution. Thus, a transition between places is equivalent to a transition to another task in the workflow. This transition may initiate an information flow or also a transition between different roles. Thus, we associate with each transition an information flow rule defined as: SR (permission, org, D 1, Enter, D 2, through(e 1,2 )) (see section 3.5.2). In association with the Petri net model a transition between two domains is equivalent to a transition between two places. The entry point to execute is defined in the information flow rule which is associated with the transition controlling the transiting to the destination domain. The definition of different entry points depends on the type of the application domain. These entry points can be activities defined by the administrator of the system to control these transitions. They can be considered a specific logging or a

98 84 Modeling WFMS and Specifying WFMS Security Policy program to execute. If the transition between two roles is defined without specific entry points, we use the auto mode of transition. Only functional conditions defined to enable the transition are considered. When a transition is associated with an information flow control rule, it can fire only if these two conditions are satisfied: 1. The transition is enabled 2. The information flow control rule is activated The control of firing different Petri net transitions implies that the whole execution of the workflow is controlled and so we ensure a secure environment to the workflow execution. In next section, we will show and clarify how to use the security policy that we define. 4.6 Secure Environment to Workflow Execution Decentralized Control Section 4.5 showed how to specify the workflow security policy as a set of OrBAC security rules. These rules take into account access and flow control without violating workflow constraints. We apply access control rules to places and information flow control rules to transitions in our WFMS Petri net model. It is straightforward to define a management procedure compliant with a given global policy if we assume that this workflow is centrally managed. In this case, a request by a subject to perform an action on an object in this workflow is authorized if (1) this request is permitted by the global security policy and (2) this action can be activated according to the workflow current marking. However, if we assume that the workflow management is distributed on several components, we can no longer assume that each component has a complete view of the workflow. Thus, our objective in this section is to derive, from the global policy, the local policy to be managed by each distributed component. For this purpose, we define an algorithm that takes as input the Petri net description of the workflow and the global security policy associated with this workflow. This algorithm provides as output the local policy. This local policy is conditioned with the context of the place. A place P i is valid, and so its operations will be executed, only if its context contains the place P i. After the end of operations execution associated with P i, the place P i is deleted from its own context. Thus, it will not be valid until another execution or another event in the Petri net adds the place in its context. The local policy dynamically changes as contexts are updated. This policy synchronizes the global policy with the execution of the Petri net. So, access to different system objects and temporal constraints are secured with this local policy. In fact, when a place P i is

99 4.6 Secure Environment to Workflow Execution 85 using a document d in mode write and another place P j must modify or access the same document after being used by P i, P i must not have access to this document when it is used by P j. This is to ensure the integrity of the system. Using the local security policy, this risk is eliminated since access to different documents and objects is controlled by contexts. Our security policy does not only deal with access control but also with information flow control. Our information flow control is based on transitions of our WFMS Petri net model. Since we use interpreted Petri nets, we can synchronize transitions and events. In our model, we consider that these events correspond to the activation of information flow control rules. A transition create a relationship between two places. If operations associated with these two places have to be executed by roles R 1 and R 2 respectively and by the same subject, a transition from role R 1 to R 2 is required. This transition is controlled using our information flow control rules associated with transitions. Thus a transition in our WFMS Petri net will be valid or activated if and only if all operations associated with its entry places finish and the information flow control rule associated with it is applied Algorithm to Deploy WFMS Security Requirements To define our algorithm, we first introduce some hypotheses, variables, functions, sets and tables. These elements are described in table 4.3. We then present the algorithm. It is based on two levels of security policy: a global security policy and a local security policy. The first one is considered an input of the algorithm. The second is provided as output to control the process execution. The global security policy takes into account all circumstances and constraints defined initially with the workflow specification and this is before the start of the workflow execution. Thus, we can consider that it is static according to the workflow execution, even if it is contextual. However, the local security policy can be considered dynamic since it depends on contexts of different execution places and so it depends on the workflow execution. Hypothesis: The initial marking of the Petri net is a token in the first place. This comes from the definition of a workflow. Proposed algorithm: The execution of the Petri net is described in algorithm 1. This algorithm assumes a Petri net representing a workflow and a global security policy as inputs. It securely executes the process by generating local contextual policies. These local policies are associated with different places of the Petri net. The algorithm starts by initializing all execution conditions to false since no operation is being executed until now. Also, each context contains initially only the

100 86 Modeling WFMS and Specifying WFMS Security Policy Variables i,j,k,n, m integer bool, result boolean Cont(P i ) context of the place P i < r k,v k, Cont(P k ) > a token where Cont(P k ) = (Pre context(p k ), temp context(p k ), exec context(p k )) Functions Card (E) = E M (P j ) Index (E) Valid transition (bool, i) returns the cardinality of the set E returns the set of tokens of the place P j returns index of different elements of the set E function which verifies if the Petri net contains a valid transition. If this valid transition exists, bool will be true and i will return its index Sets P set of places P = m T set of transitions T = n P j set of input transitions of the place P j P j set of output transitions of the place P j T j set of input places of the transition T j T j set of output places of the transition T j P {i,j..,k} = P i P j... P k, (identically for other sets) Cond j = cond(t j ) set of conditions associated with the transition T j = C ex, C 1,...,C k where: C ex = {C exi, C exj,...} set of execution conditions of input places of T j Tables Valid[1..n] Org[1..m] R[1..m] A[1..m] V[1..m] SB DB Boolean table indicating the validity of transitions table which indicates organizations of places of the Petri net table which indicates roles associated with operations of places table which indicates activities (operations) associated with places table which indicates views (objects) associated with places of the Petri net Security policies Static base of security rules Dynamic base of security rules Table 4.3: Algorithm elements

101 4.6 Secure Environment to Workflow Execution 87 Algorithm 1: Secure execution of the Petri net model 1 for i in [1... T ] do 2 3 end C ex (T i ) false /* initialisation of execution conditions */ 4 for i in index (P) do 5 6 end exec context(p i ) { P i } /* initialisation of contexts */ 7 /* processing for the first place */ 8 if (permission, Org[1], R[1], V[1], A[1], (Pre context(p 1 ), temp context(p 1 ), -)) SB then 9 DB DB (permission, Org[1], R[1], V[1], A[1], (Pre context(p 1 ), temp context(p 1 ), exec context(p 1 ))) 10 end 11 if ( o P 1 = 0 & M(P 1 )<>{} ) then 12 Execute (A[1], result) 13 end 14 if (result = false ) then 15 Exit 16 end 17 for j in index (T o 1 18 ) do if (result = true) then 19 C ex1 (T j ) true; /* execution validation associated to P 1 */ 20 Apply(flow control policy(t j )) ; /* information flow control rules */ 21 end 22 if (cond j = true) & valid (flow control policy(t j )) then 23 Valid (j) true; 24 end 25 end 26 for k in index (T o index(p 1 o )) do 27 exec context(p k ) exec context(p k ) P 1 ; 28 end 29 exec context(p 1 ) exec context(p 1 ) \ {P 1 }; 30 repeat 31 Valid transition (bool, i); /* it returns a valid transition in the Petri net and its index i*/ 32 if (bool = true) then 33 for k in index (T o i 34 ) do if (permission, Org[k], R[k], V[k], A[k], (Pre context(p k ), temp context(p k ), -)) SB then 35 DB DB (permission, Org[k], R[k], V[k], A[k], 36 (Pre context(p k ), temp context(p k ), exec context(p k ))) /* local dynamic policy */ 37 end 38 /*updating RdP marking*/ 39 M(P k ) M(P k ) <r k, v k, Cont(P k )> ; /* Cont(P k ) = (Pre context(p k ), temp context(p k ), exec context(p k ) 40 if (M(P k )<> {} & P k Cont(P k )) then 41 Apply(Coordination Policy(temp context(p k ))); /*Coordination policy*/ 42 Execute (A[k], result); 43 end 44 if (result = false ) then 45 Exit 46 end 47 for j in index (P o k 48 ) do if (result = true) then 49 C exk (T j ) true; 50 Apply(flow control policy(t j )); /* Execution of the entry points associated to the flow control rule */ 51 end 52 if (cond j = true)& valid (flow control policy(t j )) then 53 Valid (j) true; 54 end 55 end 56 for i in index (T o index(p k o )) do 57 exec context(p i ) exec context(p i ) P k ; 58 end 59 exec context(p k ) exec context(p k ) \ {P k }; /* updating RdP marking */ M(P k ) M(P k ) \ {<r k, v k, Cont(P k )>}; 60 end 61 end 62 until (bool = false) ;

102 88 Modeling WFMS and Specifying WFMS Security Policy place with which it is associated. The processing of the first place is done separately. Indeed, the test for all other places processing is done on transitions. So, if the first transition is valid (it contains at least one token) we check if the token in this place verifies the global security policy defined as an input of the algorithm. In other words, for a token <r k, v k, Cont(P k )> we check if the role r k has access to the view v k in the organization Org[k] associated with the place P k. After that, we construct the local security policy containing rules which manage execution of operations associated with each place. So, we check if execution context(p k ) contains the place P k. If it is the case, the local policy is activated. Thus, r k can execute activities associated with P k using the view v k. After finishing execution, the local policy is deactivated by subtracting P k from the set exec context(p k ). Then, we apply the coordination policy according to policies defined in section These policies are presented in table 4.2. So, to each case presented in the temp context(p k ), we have to apply the set of rules associated with it in table 4.2. Then, we have to update: 1. execution condition of transitions in relation with P k to true 2. transitions in relation with P k if all conditions associated with them are true 3. contexts of places following P k in the order of execution 4. the marking of the Petri net by removing <r k, v k, Cont(P k )> from the set M(P k ) Then, valid transitions release according to information flow control rules associated with them. In these rules, different entry points defined in the rule have to be executed in order to make the transition able to fire. So, the information flow control of the transition is activated and the entry point defined with this rule is executed. With this control the transition to next places, if the same subject has to be assigned to two places, can not imply a leakage of information since privileges of the subject are controlled before and after the entry point execution. This processing is repeated for all places of the Petri net. So, using this algorithm we can ensure a secure execution of the process. The algorithm consider two bases of security rules: 1. Static base of security rules (global security policy): security rules using a default context or initial conditions defined with the workflow specification, without taking into account circumstances of execution and coordination security rules. It defines permissions of roles on objects within an organization. It is an input of the algorithm.

103 4.6 Secure Environment to Workflow Execution Dynamic base of security rules (local security policy): security rules generated according to the workflow execution, so depending on contexts generated or built during workflow execution. It is an output of the algorithm. It changes dynamically during workflow execution. To add a contextual security rule to the dynamic base we must verify or check if there is a corresponding non contextual rule of this rule in the static base. To have a global view of the workflow specification, we can refer to the dynamic base of security rules. Contexts of the security rules include a history of different tasks that must have been executed before each task. So, grouping whole contexts we can redesign the workflow scheme. Since these contexts express different temporal relations between workflow tasks, this design is simple to be reconstructed. The algorithm does not affect initial properties of the Petri net representation. Indeed, the Petri net modeling the workflow preserves its properties of reachability, liveness and boundedness. These properties can be studied using matricial representation of the Petri net marking and graph theory [DA92]. In complexity terms, the algorithm has a polynomial execution time (in O(n 3 )). This complexity is calculated through the loops defined in the algorithm. In fact, we have, at each time, to search for a valid transition. Once the transition is found, the treatment is done for the set of input places of the transition. Then an update is applied to the set of the output transitions of these places within the same loop. So, if we suppose that n is the number of transitions and m the number of places and p the number of output transitions, the complexity of the algorithm will be n m p. If we suppose that n is greater than p and m we can consider that the complexity of the algorithm is polynomial and in O(n 3 ) Example To illustrate the algorithm, we consider a banking application of opening a banking account represented by the Petri net of figure This application includes six tasks (activities) that must be executed in a specific order associated respectively to places P 1, P 2, P 3, P 4, P 5 and P 6 : 1. T 1 : create a banking account 2. T 2 : deliver a cheque-book 3. T 3 : credit your banking account 4. T 4 : make the account operational 5. T 5 : act on the account

104 90 Modeling WFMS and Specifying WFMS Security Policy 6. T 6 : control the account Figure 4.10: Petri net banking application These tasks will be executed within the bank by four different roles: a bank agent, a responsible for the head-office of the bank, a bank advisor and the account owner. To these roles we can respectively assign the users (Alice, Bob), (Frederic), (Nora) and (John). To do so, the objects used in this application are the banking account that will be created and the cheque-book. The owner of the account has to credit his account in order to receive his cheque-book. So, T 2 and T 3 are executed in parallel but T 2 has to end after T 3. In fact if the account owner does not credit his account he will not receive his cheque-book even if it is ready. When T 2 and T 3 end, the account becomes operational and so its owner can act on its account as he likes (T 5 ). The account owner has to address his account adviser if he wishes doing some actions on his account (demand of a loan, change account options,...). Thus, the account adviser has to control the created account. Different temporal constraints of the workflow are defined using relations defined in section 4.3 as follows: (1) (T 2, T 1 ) (2) (T 3, T 1 ) (3) (T 2, T 3 ) (4) ±(T 3, T 2 ) (5) (T 4, T 2 ) (6) (T 4, T 3 ) (7) (T 5, T 4 ) (8) (T 6, T 4 ) Only some of these constraints are expressed in figure The other constraints detail the execution modes of different tasks. In this example, we consider these temporal constraints and we consider the following binding of duty constraints: 1. Task T 1 and task T 2 have to be executed by the same subject: same subject(t 1,

105 4.6 Secure Environment to Workflow Execution 91 T 2 ) 2. Task T 4 and T 6 have to be executed by the same subject: same subject(t 4, T 6 ) First of all, the constraint base that we define is consistent since it does not contain opposite relations. To execute workflow tasks, a possible assignment of users to different roles is defined as: 1. empower(bank, Alice, bank agent) 2. empower(bank, Frederic, responsible for the bank head-office) 3. empower(bank, Nora, bank advisor) 4. empower(bank, John, account owner) To define roles that have to execute these tasks we introduces the following assignment constraints (see section 4.3): 1. must execute R(bank agent, T 1 ) 2. must execute R(bank agent, T 2 ) 3. must execute R(account owner, T 3 ) 4. must execute R(responsible for the bank head-office, T 4 ) 5. must execute R(account owner, T 5 ) 6. must execute R(bank advisor, T 6 ) Using these different constraints, we define our input static global policy of this application in table 4.4. The coordination security policy is derived from different temporal constraints already presented and using different cases presented in table 4.2. We use first order logic to combine more than one context. Indeed, the security rule: O(bank, bank agent, start(t 2 ), cheque-book, done(t 1 ) start(t 3 )) is a combination of two security rules: (1) O(bank, bank agent, start(t 2 ), cheque-book, done(t 1 )) and (2) O(bank, bank agent, start(t 2 ), cheque-book, start(t 3 )). The role bank agent has to execute the tasks T 1 and T 2. We have two subjects Alice and Bob who can be assigned to this role. Since we have a constraint stating same subject(t 1, T 2 ), we have to assign the same subject to these tasks. We suppose that she will be Alice. We can suppose that even if Alice has the same role to execute the two tasks, she must undertake a specific action to get access to the application to command a cheque-book. We consider that this action is to log

106 92 Modeling WFMS and Specifying WFMS Security Policy in. This action can be considered as an entry point associated with the transition T 1. The second constraint same subject(t 4, T 6 ) is more complex. Indeed, T 4 has to be executed by a role responsible for the bank head-office. However, the task T 6 has to be executed by a role bank advisor. If we suppose that T 4 has been executed by subject Frederic, then this subject has to transit from the role responsible for the bank head-office to the role bank advisor. This change of role is controlled by the firing of the transition T 4. We suppose that to get the role bank advisor, Frederic must provide information about the account owner. Thus, we associate with the transition T 4 an information flow security rule defined as follows: (permission, bank, responsible for the bank head-office, Enter, bank advisor, through( Provide information about account owner )). The transition T 4 will fire only if the entry point is executed. The execution of the algorithm generates a local dynamic policy presented in table 4.5. This policy is the output of our proposed algorithm during the process execution. We notice through the output policy that the tasks T 1 and T 2 have been executed by the same subject Alice, T 3 and T 5 by the subject John and T 4 and T 6 by the same subject Frederic. This dynamic policy maintains the execution order of different tasks and different contexts generated are expressed through these orders. These execution contexts are generated according to the progression of workflow execution. We recall that in our security policy obligations are prior than permissions. So there is no conflict that can be generated. Also, we recall that the colour defined in the context (in this case red ) is used to identify the process execution instance. Each new execution process is defined using a new colour. 4.7 Complexity of the Workflow Satisfiability Problem A workflow specification is usually defined with a set of constraints that introduces different relations and dependencies that must be enforced either between subjects executing workflow tasks or between workflow tasks themselves. Different types of these constraints have been defined in section 4.3. Satisfying all these constraints when executing the process can be a complex task and can even lead to the non accomplishment of the workflow or to the violation of some constraints especially if the constraint set is initially not consistent. Once the workflow specification is done, the workflow manager will be wondering about its execution and whether it is possible to execute the workflow without violating the constraint base (the set of all constraints). In this part we deal with calculating the complexity of the workflow satisfiability problem (WSP). To do so, we divide the problem into three problem statements.

107 4.7 Complexity of the Workflow Satisfiability Problem 93 Global security policy General security policy P(bank, bank agent, create, banking account, default) P(bank, bank agent, deliver, cheque-book, default) P(bank, account owner, credit, banking account, default) P(bank, bank head-office s responsible, make operational, banking account, default) P(bank, account owner, act on, banking account, default) P(bank, bank advisor, control, banking account, default) Coordination security policy P(bank, bank agent, start(t 1 ), banking account, default) O(bank, bank agent, start(t 2 ), cheque-book, done(t 1 ) start(t 3 )) O(bank, account owner, start(t 3 ), banking account, done(t 1 ) start(t 2 )) P(bank, bank agent, start(t 2 ), cheque-book, default) P(bank, account owner, start(t 3 ), banking account, default) O(bank, account owner, end(t 3 ), banking account, doing(t 2 )) O(bank, bank head-office s responsible, start(t 4 ), banking account, done(t 2 ) done(t 3 )) P(bank, bank head-office s responsible, start(t 4 ), banking account, default) O(bank, account owner, start(t 5 ), banking account, done(t 4 )) O(bank, bank advisor, start(t 6 ), banking account, done(t 4 )) Table 4.4: Algorithm input policy Local and dynamic security policy P(bank, Alice, open, banking account, (red, P 1 )) P(bank, Alice, deliver, cheque-book, (red, (P 2, P 1 ))) P(bank, John, credit, banking account, (red, (P 3, P 1 ))) P(bank, Frederic, make operational, banking account, (red, (±(P 3, P 2 ), P 1 )) P(bank, John, act on, banking account, (red, ( (±(P 3, P 2 ), P 1 ), P 4 ))) P(bank, Frederic, control, banking account, (red, ( (±(P 3, P 2 ), P 1 ), P 4 ))) Table 4.5: Algorithm output policy

108 94 Modeling WFMS and Specifying WFMS Security Policy In the following we introduce these statements and we study their complexity. In this part we consider a workflow composed of n tasks and m constraints defined with the workflow specification Problem statement 1 1. Input: a set C of k constraints. C={C1, C2,..., Ck} 2. Question: Check if this set of constraints is consistent. It means that these constraints are satisfiable and they are not contradictory. 3. Complexity: this problem has a polynomial complexity in time (O(k 2 )). 4. Proof: To study the complexity of this problem, we suppose that a constraint base contains a set of relations and their opposite. First of all, we focus on one type of relation. Then the same work can be done for the rest of relation types. W = {T1, T2,.., Tm}, a workflow of m tasks. C = {ρ1(th, Ti), ρ2(tj, T6), ρ1(tl, Tj),..., ρ2(tl, Tn), ρ1(th, Tj), ρ1 (Th, Ti),..., ρ2 (Tj, Tm)} a constraint base of k elements where ρa belongs to {same subject, same departement, different team,... } and ρb is the opposite relation of ρa (for instance, same subject and different subject are two opposite relations). Formally, we can state that: if ρ is a positive relation which relates T i and T j, then the negative relation ρ of ρ is defined as ρ. Thus we conclude that ρ ρ. Let us consider Ci different sets which contain different relations ρi and ρi where i in [1..k]. This set of relations can include even temporal constraints. Indeed, the same approach can be applied to these constraints since we suppose that the two constraints begin with and end with are respectively opposite to begin after and end after. The mechanism of inconsistency detection is described by the algorithm 2. The basic idea of this algorithm is to calculate different equivalence classes of each positive relation. These equivalence classes are defined in sets S i. These sets are defined through the set G which contains all constraints defined for a specific positive relation. Then, after defining all equivalence classes, we check if there is an inconsistency with negative relation. To do so, we compare the two arguments of a negative relation to elements of the equivalence class of the positive relation corresponding to this negative relation. If these two arguments belong to the same equivalence class, then an inconsistency is detected. The complexity of checking if a set of constraints

109 4.7 Complexity of the Workflow Satisfiability Problem 95 is consistent is similar to the complexity of algorithm 2. Therefore it has the complexity of defining equivalence classes and then comparing them to negative relations.this complexity is polynomial in time (O(k 2 ), where k is the number of constraints). The functions First arg() and Second arg() used in the algorithm return respectively the first and the second argument of a binary relation in the constraint base. For example if we have the relation ρ = same subject(t1, T4) we will have First arg(ρ) = {T1} and Second arg(ρ) = {T4}. As an example of a non consistent constraint base, let us consider this constraint base: 1. same subject(t1, T2) 2. same subject(t3, T6) 3. same subject(t2, T3) 4. different subject(t1, T6) We can easily notice that these constraints can not be consistent since tasks T1 and T6 must be done simultaneously by different users (constraint 4) and by the same user (combining constraints 1, 2 and 3) Problem statement 2 1. Input: a workflow W of n tasks, a set of users and a set of m consistent constraints. 2. Question: can we find a valid assignment of users to different tasks which satisfies all constraints? 3. Complexity: this problem is NP-complete. 4. Proof: This problem is similar to the problem called Constraint Satisfaction Problem (CSP) defined as We give a set of variables, a finite and discrete domain for each variable, and a set of constraints. Each constraint is defined over some subset of the original set of variables and limits the combinations of values that the variables in this subset can take. The goal is to find one assignment to the variables such that the assignment satisfies all the constraints [VIP]. Many optimized backtracking techniques [VIP, YDI98] are proposed to solve this problem. To prove that it is a NP-complete problem, we use a reduction

110 96 Modeling WFMS and Specifying WFMS Security Policy Algorithm 2: Checking the coherence of a constraint set 1 coherence true 2 for l in index(ρ) do 3 G {ρ l } 4 i 1 5 repeat 6 S(i) {First arg(g(1)), Second arg(g(1))} 7 G G \ G(1) 8 j First index(g) 9 repeat 10 if (First arg(g(j)) S(i)) then 11 S(i) S(i) {Second arg(g(j))} 12 G G \ G(j) 13 j First index(g) 14 if (Second arg(g(j)) S(i)) then 15 S(i) S(i) {First arg(g(j))} 16 G G \ G(j) 17 j First index(g) 18 if (First arg(g(j)) / S(i)) and (Second arg(g(j)) / S(i)) then 19 j Next index(g) 20 until (j > Last index(g)) ; 21 for all element e of ρ l do 22 if (First arg(e) S(i)) and (Second arg(e) S(i)) then 23 coherence False i i+1 until (G = ) or (coherence = False) ;

111 4.7 Complexity of the Workflow Satisfiability Problem 97 to the colorability problem. First of all, let us recall this problem. Colorability problem: Let G be a graph with vertices V and edges E. The graph G is 3-vertex-colorable if there is a surjective (onto) function f : V {a,b, c} such that if two vertices v,w V are adjacent (connected by an edge) then f(v) f(w). This means that out of three colors we assign one color to each vertex such that no two adjacent vertices are colored with the same color. The n-colorability problem is defined similarly. We represent the workflow as a graph where its vertices represent different workflow tasks and its edges represent the constraints defined between the tasks connected by these edges. We associate each relation of the constraint base with a graph where we represent just this specific relation. So the whole graph representing the workflow will be represented as a set of sub graphs representing different relations of the constraint base. Each sub graph contains just the relation (ρi) and its opposite ( ρi). For example let us consider a workflow W = {T1, T2, T3, T4, T5, T6} and a constraint set containing these constraints: same subject(t1, T5) same subject(t3, T6) different subject(t1, T2) different subject(t2, T4) different subject(t5, T6) The figure 4.11 represents the sub graph corresponding to the same subject relation of the constraint set (we represent this relation using the symbol =). Then we transform this graph by gathering tasks that must be executed by the same subject in the same vertices. This transformation leads to the graph in figure We apply the same treatment to all relations in the constraint set. So, searching an assignment that does not violate these constraints can be expressed as a set of graph colorability problems which is known in its simplest form as a way of coloring the vertices of a graph such that no two adjacent vertices share the same color. In this reduction, vertices in a graph are mapped to steps in the workflow, while colors are mapped to users. The graph colorability problem is NP-complete. So, finding a valid assignment of users to different tasks which satisfies all constraints is also NP-complete. This problem has been studied in [BFA99]. Indeed, Bertino et al. propose a solution to this problem. This solution consists in defining all assignments that can

112 98 Modeling WFMS and Specifying WFMS Security Policy be defined with the workflow execution and without violating the set of constraints. This approach enumerates all possible and valid assignments. The complexity of this approach is exponential and it especially increases when the set of constraints is important. In this approach, the consistency of the constraint base is initially checked. So, the set of assignments is defined with a constraint base which is supposed consistent Problem statement 3 Figure 4.11: Initial graph of the = relation 1. Input: a workflow instantiation of n tasks and a set of m consistent constraints. 2. Question: Does this assignment satisfy all constraints or not? 3. Complexity: this problem has a polynomial complexity in time. (O(nxm), n the number of tasks and m the number of constraints). 4. Proof: To study the complexity of this problem, we represent the workflow as a deterministic Turing machine. Different tasks represent different states of the machine. The assignment of different subjects to different tasks corresponds to the entry of the Turing machine. At each state of the Turing machine, we check if the assignment of the first subject to the task of this state satisfies all constraints associated with the workflow. Then this subject will be deleted from the entry and then the new entry will be passed to the next state of the

113 4.7 Complexity of the Workflow Satisfiability Problem 99 Figure 4.12: Reduction of the = relation graph machine. These steps are done until the end of the workflow. This process is described by the algorithm 3. The complexity of this algorithm is polynomial (mxk; m: number of tasks and k: number of constraints). In each state we must do k checks with the constraint base. This operation is repeated m times, the number of states (equal to the number of tasks). Algorithm 3: Main Algorithm 1 Entry chain affectation subjects 2 result True 3 repeat 4 cursor i 5 Affect (T i, Entry chain[1]) 6 Check (constraint base) k operations 7 if check(constraint base) then 8 Entry chain Entry chain \ Entry chain[1] 9 if not (check(constraint base)) then 10 result False 11 until (i = k)or (result=false) ;

114 100 Modeling WFMS and Specifying WFMS Security Policy Discussion As we have seen, the complexity of the Workflow Satisfiability Problem depends on the set of constraints and also on the assignment defined for different users to different roles. We notice that the consistency of the constraints base affects directly the assignments that can be done for the workflow execution. [WL07] has studied this problem without checking the consistency of constraints base. If we do not suppose that the constraints base is consistent, the complexity of the problem can be exponential. This hypothesis is not considered in [WL07]. In this work, WSP is NP-complete in R 2 BAC. R 2 BAC extends RBAC by adding the two binary relations of = and. The approach that we use to study the problem is clearer than the one used in [WL07] and it takes into account the complexity of checking the constraints base. In [BFA99], the problem was treated and resolved but the complexity of the problem was not studied formally. The proposed solution can explode if constraints are very numerous. In this work, many constraints have been taken into account but the workflow execution is considered only sequential. 4.8 Conclusion In this chapter, we have presented a Petri net based model for modeling workflows and we have defined its associated security policy. To do so, we have used our integrated model defined in the previous chapter. This model and security policy are based on OrBAC concepts. Thus, they reuse organization and context notions defined in this access control model. Our security policy takes into account different possible constraints between two tasks and it especially deals with temporal constraints. It is composed of a general security policy, a coordination security policy and an information flow policy. In a second part, we have presented an algorithm allowing us to synchronize authorization flows with workflow execution. This algorithm defines how to execute the suggested model in a distributed WFMS environment. The algorithm takes as input the Petri net model of the application and the global security policy (considered static) assigned to it and provides as output a local security policy (considered dynamic) controlling the distributed execution of different workflow tasks by different workflow agents. The last part of this work investigates the complexity of the workflow satisfiability problem. This problem was divided into three sub-problems: (1) complexity of checking if a constraint set is consistent which has polynomial complexity, (2) when the set of constraints is consistent, complexity of finding a valid assignment of users to different tasks which satisfies all constraints which is a NP-complete problem and (3) Given a workflow instantiation and a set of consistent constraints, complexity of checking if this assignment satisfies all constraints or not. We showed that this last problem has a

115 4.8 Conclusion 101 polynomial complexity. Our approach provides an alternative to the static and centralized approach suggested in models already proposed and detailed in section 2.7 of chapter 2. These works do not take into account different execution modes within the workflow and consider only the sequential execution [AH96, AAH98]. Also, their security policy only deals with access control. Our approach extends these works by proposing a dynamic management of workflow authorizations and by taking information flow control into account. In our approach, information flow control is based on the DTE model which provides more flexible control than those suggested in [AH97, AHB98, NO94] which are based on Bell and LaPadula. Besides, we considered within the security policy different constraints that can be defined with the workflow specification, especially temporal constraints. With such an approach, we ensure a secure environment of workflow execution without affecting the functional or the security requirements of the workflow.

116

117 Chapter 5 Deploying security policy in intra and inter WFMS 5.1 Introduction Many research works have been interested in WFMS security but no study has addressed the deployment part. As detailed in chapter 2, several proposals [AAH98, AH96, HA99, HK99, BFA99] suggest different access control models to manage security in WFMS without defining how to implement such a policy. They have only defined a centralized procedure that controls the execution of the workflow. These works suppose the existence of a central entity responsible for specifying and managing the workflow security policy without showing how such a policy will be used. They do not deal with the communications required to apply the workflow security policy. Also, they do not show how this security policy can be dynamically supervised during the workflow execution. In chapter 3, we have defined a security policy that deals with both access and information flow controls. Then we have showed in the previous chapter how this security policy will be applied to our Petri net model. In the previous chapter, we have also presented a decentralized procedure to execute the workflow in a secure manner using the integrated model defined for access and flow control. In this chapter, we show the whole process and agents included to execute the workflow. We show how these agents ask for executing tasks and how the security of the workflow is managed once the workflow specification and the security policy are well defined. We present the deployment approach that we have to use either in the intra or the inter organizational workflow. This chapter focuses on how to manage the workflow security policy. It answers to the following questions: 1. Who defines the workflow security policy?

118 104 Deploying security policy in intra and inter WFMS Figure 5.1: Centralized and distributed workflow 2. Who is responsible for maintaining a secure execution environment? 3. Who is permitted to manage the workflow security policy? The chapter introduces PEP and PDP entities required to deploy the security policy within the workflow. We show how these entities have to communicate with workflow components in order to synchronize and manage the security policy. We then show how to deploy a workflow policy as it is defined and specified in chapter 3 and how it must be applied to different components of the workflow. The deployment depends necessarily on the execution mode and type of the workflow (intra or inter organizational workflow). For the inter-organizational case, a new entity called VO (Virtual Organization) will be needed to manage different communications between different organizations. As a matter of fact, this VO will be also responsible for ensuring a secure information flow control. Its policy will be also based on the security policy defined within our integrated control model. We published the work of this chapter in [ACBC09a]. The chapter is organized as follows. Section 5.2 introduces the functional approaches of workflow management systems. It presents their centralized and distributed modes and their intra or inter organizational types. Section 5.3 introduces provisioning and outsourcing approaches to manage security policy within a workflow. Section 5.4 explains how to deploy the security policy associated with WFMS and how to use the OrBAC model for this purpose. It specifies our approach to deploy a security policy either in intra or inter organizational workflow. Section 5.5 exemplifies the inter-organizational case through a telesurgery application. Finally, section 6 concludes the chapter.

119 5.2 Functional approaches of WFMS Functional approaches of WFMS Centralized and distributed workflows A WFMS can be executed either in centralized or distributed modes. With a centralized control, there exists a single central WFMS which is responsible for: 1. distributing the tasks to the appropriate agents 2. ensuring the task dependencies by sending the tasks to the respective agents only when all requisite conditions are satisfied This entity has a global view of the workflow. It is the initiator of the workflow and it evaluates execution results in order to choose the next agent to whom it will send the next task. In this mode, workflow agents do not know the dependencies between each other. In the distributed execution mode the whole workflow is sent by the initiator to the first agent A 1. After the execution of the first task associated with the agent A 1, A 1 evaluates the dependencies with its successors. The rest of the workflow is then sent to the valid successor depending on the result of the first task. Finally the last agent sends the final result to the central entity which initiated the workflow. In this mode, workflow agents know the different dependencies with other agents. Especially, each agent knows its successors and conditions that are needed to transit from a task to another. Also different constraints defined with the workflow specification are ensured by different agents which have to check if they are respecting workflow constraints when executing different tasks. These two modes are represented in figure Intra and inter organizational workflows Workflow tasks can be executed within the same organization or within different ones. We respectively call these cases intra and inter organizational workflows. Intra-organizational workflows are simpler to manage since all process requirements (resources, subjects...) belong to the same organization. In the inter-organizational case, specific requirements are needed. Figure 5.2 represents an inter-organizational workflow. Tasks of this workflow belong to three different organizations (ORGA, ORGB and ORGC). These tasks can belong or not at the same time to other local workflows in their own organizations. As a functional requirement, the execution of an inter organizational workflow needs synchronization between the execution of different sub-workflows that participate in the collaboration. As a security requirement, we have to deal with interactions between these different organizations. The execution of an intra-organizational workflow can be either centralized or distributed as it is explained in section The execution of inter-organizational

120 106 Deploying security policy in intra and inter WFMS Figure 5.2: Inter-organizational workflow workflows can be considered distributed since each sub-workflow is executed within an independent organization. But the coordination between these different organizations can be done either by these organizations themselves (distributed mode) or through a central entity which deals with the synchronization and the orchestration of different sub-workflows (centralized mode). 5.3 WFMS Security policy management Functionally, the central entity of a workflow can be either a coordinator entity which controls the whole execution of the workflow in a centralized workflow or just an initiator entity in a distributed workflow. Concretely, this entity can be either a human being who can pass orders or an application which initiates other applications. This entity will be also responsible for the security of the workflow. For this aspect, a choice must be done by the workflow administrator, i.e. the security requirements may be managed either using an outsourcing approach or a provisioning approach Outsourcing approach In this approach, the central entity of the workflow is also responsible for the workflow security. Figure 5.3 represents this approach within a centralized and distributed workflow. Arrows in this figure show different communications during the workflow execution. For the distributed workflow, blue arrows show communications between different agents and the central entity of the workflow to ask for permissions in order to execute tasks. We notice that access to the security policy is only done by the WFC (Workflow Coordinator). Using this approach, workflow agents have

121 5.4 Deploying WFMS security policy 107 to ask for permissions to execute workflow tasks to the central entity. This central entity has to check if the agent is authorized to execute the task depending on the workflow security policy and the workflow specification which includes workflow constraints. Even if the execution of the workflow is distributed, the central entity will need all information required about the execution progression when it is asked for a permission by workflow agents. The security policy is managed by the central entity. The different worklow agents do not have any knowledge about it. They have just the obligation to ask for a permission to execute requested workflow tasks. The central entity synchronizes the security policy with the execution progression of the workflow Provisioning approach In the provisioning approach, the central entity delegates the workflow security requirements to different agents. So, if an agent needs to execute a workflow task it will not ask permission to the central entity but it will search it from a security server. This check is done by all workflow agents. This approach reduces the bulk on the central entity but it increases the execution time on the workflow agents. Figure 5.4 represents this approach with a centralized and a distributed workflow. Arrows in this figure show different communications during the workflow execution. We notice that access to the security policy is done by workflow agents. With this approach the central entity has no security functionalities. It does not deal with the security part which is managed by agents. 5.4 Deploying WFMS security policy With the diversity of resources, roles and tasks in a workflow, the deployment of a WFMS security policy becomes a critical issue. In this section we show how to Figure 5.3: Outsourcing in a centralized and a distributed workflow

122 108 Deploying security policy in intra and inter WFMS Figure 5.4: Provisioning in a centralized and a distributed workflow manage such a security policy either in an intra or inter organizational workflow. The second case is more complex since it deals with different communications between organizations cooperating to execute the global workflow. We use OrBAC to specify our security policy. As shown before, this model is able to represent confinement aspect using the organization concept Intra-organizational case The deployment of the security policy depends on the execution mode of the workflow and on the approach that we are using to manage the policy. For the intraorganizational case, we suppose that we deal with a distributed workflow. In a centralized workflow, all communications in the workflow are done through the workflow coordinator (WFC). Figure 5.5 represents a general scheme for deploying a WFMS security policy using the outsourcing approach. The explanation in this section follows the numbers on the arrows in the figure Specification environment As shown in figure 5.5, the general scheme is divided into a specification environment and an enactment environment. (1) The definition of the workflow specification takes place. The process designer provides a written or a graphic specification of the different tasks of the workflow

123 5.4 Deploying WFMS security policy 109 and of the roles that have to execute these tasks. Also, the designer defines different constraints associated with the workflow definition. (2) Different specification components are transmitted to a modelling tool. As we have showed in the previous chapter, Petri nets are an efficient tool to model workflows. Aside representing the workflow evolution, Petri nets can take into account temporal constraints that may be defined with the workflow. With Petri nets, it is possible to specify that the execution of activities must be done in sequence, or in parallel, or that a choice has to be made between activities (alternative activities), or that certain activities need to be executed more than once (iterative activities). Chapter 4 details an approach using Petri nets to represent workflows as we propose it. (3) Once the workflow is modelled, the process modelling tool communicates with a process verification engine to check if the workflow is well formed. If the workflow is modelled using Petri nets, there are Petri nets properties (correctness, liveness, well-structuredness, soundness,...) that must hold to conclude that the workflow is well defined and specified. (4) Once the workflow is well formed, workflow constraints are checked. Constraints validation engine checks the consistency of constraints defined with the workflow specification. (5) The policy server has to get information about the workflow specification, so that the security policy can be specified. Thus, the process modelling tool transmits workflow information (roles, tasks, objects, constraints) to the server policy. Based on these elements, the policy server specifies the workflow security policy to be used to ensure a secured execution of the workflow. (6) The OrBAC API creates the workflow security policy and saves it into a policy repository (PR). The OrBAC API is able to: Load and save security policies under XML RDF files Create and edit the OrBAC policy Evaluate contexts Interrogate the concrete security policy The policy initially defined is an abstract policy which is based on abstract entities defined in the OrBAC model. From this abstract policy saved in the PR, a concrete policy will be derived when the workflow is instantiated. This policy is defined with non active contexts. These contexts contain initial constraints defined with the workflow specification. With the progression of the workflow execution,

124 110 Deploying security policy in intra and inter WFMS these contexts are updated and activated in order to make the security rules applicable. The process modelling tool provides the workflow specification to the process enactment engine. Then we move to the enactment environment Enactment environment It manages the workflow instantiation. In this environment the workflow specification moves to the run time phase. The user assignment is done at this phase depending on the workflow specification. The steps below define the next phases to be done once the workflow specification is ready. In this section, we actually present a decentralized approach to execute the workflow. Regarding the security part, the outsourcing approach is used. So, the WFC is responsible for the security of the workflow execution. To manage the security policy, the WFC needs a PEP (Policy Enforcement Point) in order to deal with different policy instances. This logical entity is responsible for controlling access to different system resources. Before starting the workflow execution, the WFC has to know how to manage the workflow security policy. So, communications with the policy server are initiated. On the side of the policy server, there is a PDP (Policy Decision Point) who is responsible for communicating with the security client and for replying to its different requests. When a user tries to access a file or other resources on a computer network or server that uses policy-based access management, the PEP will describe the user s attributes to other entities in the system. The PEP will ask the PDP whether or not to authorize the user based on the description of the user s attributes. (7) In the process enactment engine, the WFC entity deals firstly with the assignment of users to different roles and tasks. This assignment is based on a communication with different users and external applications that can participate to the workflow execution. 1 (8) The assignment made by the WFC must be checked with respect to the workflow constraints. Such an assignment must not make the constraint base inconsistent. So the process enactment engine has to communicate with the constraints validation engine to validate its assignment and to apply it. (9) The PEP sends a request to the PDP. The request must contain information about the assignment of users to different tasks and the different contexts of the workflow execution. Then, the PDP receives the request. This logical entity or place on a server makes admission control and policy decisions in response to a request to access system resources. (10) After receiving concrete entities and information about the workflow execution, the PDP communicates with the PIE (Policy Instantiation Engine) to ask for the concrete policy. 1 For a pervasive environment of workflows, see [MM07a, MM07b]

125 5.4 Deploying WFMS security policy 111 (11) The PIE is responsible for generating a concrete security policy based on information received from the PDP and the abstract policy saved in the PR. The PIE updates contexts and transfers the new security policy to the PDP. (12) The PDP takes the policy decision. Whenever it receives a new policy instance, i.e. a concrete rule (permission or prohibition), a PDP has to map this piece of information onto concrete actions to push the new policy into the PEPs. Thus, the PDP has to be aware of the PEPs capabilities, so that it can translate the security rules into generic configurations and then the generic configurations into specific configurations, considering the implementation of the PEP. So, the PDP translates the concrete policy into a translatable language and stores it into a PIB (Policy Information Base). Applicable policies are stored on the system and are analyzed by the PDP. (13) The PDP makes and returns the decision. The PEP will let the user know whether or not he or she has been authorized to access the requested resource. (14) The PEP sends an acknowledgment to the PDP to inform about its acceptance of the PDP decision and how it will apply it. (15) Once the workflow specification and a consistent policy has been defined, the WFC initiates the workflow. It sends the whole specification to the first agent that will execute the first task of the workflow. Since this workflow execution is distributed, each agent responsible for executing a task, sends a request to the WFC in order to grant him the authorization to accomplish the task. These requests are represented by blue arrows in figure 5.5. When the WFC receives such a request, it takes the decision to accept the accesses. Then, it sends a response to the workflow agent including the permission or prohibition to execute the task. After the first task, agents have to send the execution context to the WFC. This context provides information about the progression of the workflow. The WFC needs such information to be able to update its policy. In fact, when a request is received from a workflow agent, the WFC has to communicate with the PDP and steps 9-14 are executed for each communication between the WFC and workflow agents. The execution context especially indicates about previous tasks that have been accomplished. If we consider for example a workflow where a task T 4 can be executed only if task T 1 has been executed successfully and then tasks T 2 and T 3 have been executed in parallel and successfully, then the authorization is granted to agent executing T 4 only if the execution context holds and the WFC is informed about this. Steps (16) and (17) show the functional communication between workflow agents. Blue arrows show the requests for the authorization rules from the WFC. (18) The last agent sends the workflow result to the WFC, and so the workflow execution completes. If we consider that the execution of the workflow is centralized, the communication between WFC and workflow agents to ask for authorizations will not exist.

126 112 Deploying security policy in intra and inter WFMS Figure 5.5: Security policy deployment using a provisioning approach The WFC will actually send the task and the authorization associated with the task execution to the workflow agent and the agent will respond with the execution result. By receiving this result the WFC will update its security policy and select the next agent depending on the result of the task execution that it has received. If we suppose that the security policy is managed using the provisioning approach, then the WFC will have no idea about the security policy to be deployed during the workflow execution. Also, workflow agents will communicate directly with the policy server to ask for an authorization to execute their tasks. Thus, each workflow agent will have a Local PEP (LPEP) and these LPEPs will communicate with the PDP present on the policy server. In addition to information about their capabilities, LPEP have to communicate to the PDP information about the workflow execution progress Inter-organizational case For inter-organizational workflows, several workflows are involved in the achievement of a common objective. Interactions between different organizations are necessary in this case. Such communications have to be well controlled since each organization has its private information, its private policy and its own characteristics. A communication protocol is needed in order to ensure these different communications and flows that can transit from an organization to another. This requirement is critical

127 5.4 Deploying WFMS security policy 113 especially to enforce the constraints defined in the workflow specification. These different constraints have been detailed in the previous chapter. If these constraints are defined within the same organization, the WFC can enforce and check if its user role assignment violates the base of constraints or not. Otherwise, if we suppose for example a constraint that specifies that task T i must start before task T j and that task T i is provided by an organization OrgA and task T j is provided by an organization OrgB, enforcing workflow constraints becomes more complicated. Indeed, synchronization of tasks between different organizations must be done in order to enforce constraints Creation of VO To ensure different workflow constraints, workflow organizations have to communicate between each other. These organizations have to be synchronized even during the workflow execution. As a matter of fact, changes can happen during the workflow execution. These changes can affect the whole execution of the workflow. Thus, they must be communicated to different organizations of the inter-organizational workflow. To ensure this synchronization, we need an intermediate entity which can be able to manage different communications between workflow organizations. In an interoperability environment, inter-organizational workflows need to introduce the concept of Virtual Organization (VO) to manage organizations communications. As shown in chapter 2, this concept is introduced to remedy limitations of client/server architectures. The concept of VO is also used for security reasons in [Com09]. This entity is introduced in order to synchronize execution of tasks between different organizations and to enforce different workflow constraints. The VO is responsible for the secure inter-organizational communications. To create a VO, the inter-organizational workflow coordinator (IWFC) sends requests to different organizations participating in the global workflow. Receiving these requests inviting them to join the VO, WFCs have to answer the IWFC to inform it about their decision to participate in the VO. Once the agreement is achieved, the WFCs must communicate to the IWFC information about their local workflow. They must especially inform the IWFC about the constraint base. This piece of information includes the role task and the user role assignments that the WFC had defined within its organization. So, each organization OrgI sends to the IWFC a set of information defined as: {(T i, R i, U i ), IC i }. The first triple means that the user U i is assigned to the role R i to execute the task T i. The second argument is the set of inter-organizational constraints defined within the organization OrgI. This set includes constraints defined within the organization OrgI and having dependencies with other organizations. Receiving these pieces of information, the IWFC will have a global vision of all organizations. So, the IWFC has to check the consistency of

128 114 Deploying security policy in intra and inter WFMS global workflow constraints. The IWFC verifies if the different assignments received from different organizations violate or not the set of inter-organizational constraints of the global workflow. If an inconsistency is detected, the IWFC transmits the information to organizations concerned by this inconsistency. These organizations have to re-assign a new user to the role and task causing the conflict. Then this new assignment is sent to the IWFC who checks again the inter-organizational set of constraints. These communications between the IWFC and different organizations continue until obtaining a consistent inter-organizational constraints base VO security policy Based on the different constraints that the IWFC gathers, it has to define a coordination security policy and to administrate it in order to ensure the non violation of the constraints during the workflow execution. To define its policy, the IWFC must transform the constraints base into a set of security rules. These security rules constitute the inter-organizational policy of the global workflow. To communicate with each other, organizations have to be controlled by this policy. Most workflow constraints are based on tasks of the workflow and subjects executing these tasks. So, the VO has to manage the transition of subjects from an organization to another. The VO security policy must be consistent with the different local security policies of organizations. Also, it must have a higher priority than local policies. For example, let us consider the following constraint: Task T 2 (sign a check) of organization OrgA and task T 4 (validate a mission) of organization OrgB must be executed by the same subject. The IWFC can receive this constraint either from the OrgA or from the OrgB. These organizations know about the inter-organizational constraints that they must satisfy but they do not know how to ensure such a type of constraints. Indeed, each organization does not have the security policy of the other organization. So, a third part, which is the VO, is responsible for managing this communication. The subject who will execute the task T 2 into the organization OrgA can have a different role when executing the task T 4. Initially, for these two tasks, OrgA and OrgB can respectively define these rules and role assignments in their local security policies: 1. security rule(permission, OrgA, clerk, sign, check, nominal). empower (OrgA, Alice, clerk). 2. security rule(permission, OrgB, manager, validate, mission, nominal). empower (OrgB, John, manager). We notice that these assignments do not violate the local base of constraints of each organization. However, they do not respect the inter-organizational constraint

129 5.4 Deploying WFMS security policy 115 defined above. This violation is detected by the VO who informs the two organizations and so these two organizations try to satisfy the inter-organizational constraint. We suppose that in organization OrgB the subject Alice can be empowered into the role manager. Thus, the change will happen within OrgB who will redefine its local security policy and then we obtain respectively for OrgA and OrgB the following rules and role assignments: 1. security rule(permission, OrgA, clerk, sign, check, default). empower (OrgA, Alice, clerk). 2. security rule(permission, OrgB, manager, validate, mission, default). empower (OrgB, Alice, manager):- empower (OrgA, Alice, clerk), security rule(permission,orga, clerk, sign, check, default). To be sure that the subject Alice is executing the task T 2 of OrgA, the WFC 1 (coordination entity for OrgA) has to inform the IWFC about the execution progress of its workflow. Such a communication allows the IWFC to update its security policy and its different contexts. Indeed, if we suppose that when the task T 2 will be executed, Alice will not be ready to perform the task, the WFC 1 will be obliged to change the subject executing the task and must inform the IWFC about this change. In this case, the IWFC will contact WFC 1 who has to update its assignment depending on the occurred change. If OrgB can not assign the subject Alice to the role manager, OrgA has to change its assignment to execute the task T 2. At the end, an agreement must be achieved without violating different inter-organizational constraints. So, to enforce the constraint above, Alice has to switch from the role clerk within the organization OrgA to the role manager within the organization OrgB. This transition may imply a leakage of information. The problem is more dangerous if Alice transfers a confidential or sensitive data. This confinement problem has to be managed using an information flow control policy managed by the VO. To define this policy, we have developed the integrated model defined in chapter 3. The policy specification defined in this chapter consider not only the access control but also the information flow control. To integrate the information flow requirements we have used concepts defined in the DTE model. In chapter 3 we have especially considered the intra-organizational case. In the inter-organizational case we notice that the need is imposed. The basis of the security policy are the same as the one of the intra-organizational case. What differs in this case is the definition of the context of information flow rules. We recall that to be consistent with the OrBAC model, a domain corresponds, within an organization, to a role. The entry points to a domain correspond to

130 116 Deploying security policy in intra and inter WFMS different roles assigned temporarily to a subject which does not belong to the organization where these roles are defined. Thus, to define its security policy, the IWFC sends a request to different organizations to get their entry points to their different roles (i.e. domains). Then the IWFC security policy is a set of rules defined as: security rule(permission, VO, D i, Enter, D j, through(e i,j )) IWFC rules are specified as specific OrBAC rules. The rule above expresses the transition between the domain D i belonging to an organization Org i to the domain D j belonging to an organization Org j and uses the entry point concept to define a new context in order to preserve secure information flows and to keep DTE concepts. Through(E i,j ) context: it is a composed context as defined in chapter 3. In the inter-organizational case, this context is enriched and it is defined by an organization Org j as Through(E i,j ) = {E i,j, Pr j, coming from(org i )}. The first argument represents the activity to execute in order to enter a domain. This activity can be implemented as an action on the system or a program to execute or a procedure to be released. The second argument gives the set of privileges that will be granted to the subject who intends to enter a domain D j when coming from a domain D i. This set of privileges depends on the activity executed to enter the domain. So, to each entry point corresponds a different set of granted privileges. Since the entry points can also depend on different organizations from where subjects are coming, we define the last argument coming from(org i ). For example, let us suppose that we have two organizations Org j and Org k which define a role secretary. If two subjects having this role and coming respectively from Org j and Org k need to move to a role clerk in the organization Org i, they will not necessarily get the same set of privileges even if they execute the same entry point. This results from different sensitivity degrees of different organizations and also from the relationship between the organizations. For instance a special privilege can be granted to subjects coming from an organization and moving to an organization with which some agreement has been established. This context can be composed with other OrBAC contexts. Then it may include extra conditions and circumstances to supervise flow control. We notice that the communication between different WFCs and the IWFC are considered secure and all organizations are considered belonging to the same trust alliance. In other words, the VO is considered secure and IWFC has a high confidence degree to manage different communications between different workflow organizations. If it was not the case, the policy of the IWFC would be much more complicated and more dynamic. All communications have to transit through a trust server to communicate information about actual status and about the local workflows progress.

131 5.5 Case study: telesurgery Inter-organizational deployment With the inter-organizational case the same approach of deployment defined for the intra-organizational case can be applied. The specification environment still does not change. In the enactment environment, communications are more complicated. The WFC is replaced by the IWFC for the inter-organizational coordination entity and each WFA is replaced by the WFC of each organization. Then, different communications between organizations are done as described in sections and Once the VO is well formed, the IWFC of this VO communicates through its PEP with the PDP of the policy server to request the policy decision. With the outsourcing approach this entity will maintain the security of the inter-organizational workflow during its execution. If we are in a provisioning approach, each organization has to implement its local PEP (LPEP). This LPEP is used to communicate directly with the policy server without passing by the VO. This virtual organization will be useful just for the functional part of the workflow. The next section exemplifies the inter-organizational case to show the evolution of the security policy during the workflow execution. 5.5 Case study: telesurgery Telesurgery can be considered an interesting inter-organizational workflow. The application includes at least two independent organizations; i.e. two hospitals, which have to collaborate in order to achieve a common goal. This goal is generally to operate successfully a patient. This application has to enforce precise temporal constraints when it is executed. These constraints consist especially on the very precise parallelism requirements to be enforced between the two sites connected to the application. In this example, we suppose that we have a telesurgery operation between the hospital of New York and the hospital of Strasbourg. The patient is located in the hospital of New York. This organization is composed of two sub organizations: the robotic team and the medical team. In the robotic team, the robot and a set of technicians will act. In the medical team, assistants will survey the evolution of the patient state. The remote doctor is located in Strasbourg hospital. This doctor will manage a surgical console which controls the move of robot s arms in the sub organization robotic team. The reproduction of the doctor actions must be done with accuracy in real time by the robots s arms. In the following, we define the set of different elements of the application. The figure 5.6 shows a representation of a simple and general workflow of principal activities to do during a telesurgery operation. The two states S and E represent respectively the initial and the end states of the workflow. Organizations = {Strasbourg hospital, NewYork hospital}

132 118 Deploying security policy in intra and inter WFMS Sub organizations(newyork hospital) = {robotics team, medical team} Roles = {surgeon, assistant, technician, anaesthetist, robot} Views = {surgical console, patient, medical record, robot s arms, video display terminal} Contexts = {bleeding, non reaction to anaesthetic (NRA), reaction to anaesthetic (RA)} Activities = {T 1, T 2, T 3, T 4, T 5, T 6, T 7, T 8, T 9, T 10 } where T 1 = Initialize robot s arms, T 2 = Create a working zone, T 3 = Command the surgical console, T 4 = Reproduce the doctor actions on the console, T 5 = Stop the action of robot s arms, T 6 = Reanimate the patient, T 7 = Supervise vital parameters of the patient, T 8 = Update the online information of the patient, T 9 = Carry over the operation, T 10 = Supervise robot s actions. In this example we are especially interested in the enactment environment of figure 5.5. We suppose that our workflow is well formed and that all constraints are not violated. Numbers used in this section refer to different rows defined above in figure 5.5. In step 5, the policy server will receive information about the workflow to specify its security policy. This information is the assignment of different roles to different tasks within different organizations. For this purpose, we use the function assignment(org) to specify the set of assignments done within Org during the workflow specification. This set is composed of a quadruple (T, R, O, C) meaning that the task T has to be executed by the role R using the object O and satisfying the conditions C. If there is no condition this field will be empty represented by -. We can consider also that Org can be a sub organization. assignment(strasbourg hospital) = {(T 1, surgeon, surgical console, -), (T 2, surgeon, surgical console, -), (T 3, surgeon, surgical console, -)} assignment(robotic team) = {(T 4, robot, robot s arms, -), (T 5, technician, robot s arms, bleeding), (T 6, anaesthetist, patient, R.A)} assignment(medical team) = {(T 7, assistant, video display terminal, -), (T 8, assistant, medical record, N.R.A), (T 9, assistant, medical record, -), (T 10, assistant, video display terminal, -)} Using these assignments about the workflow specification, the policy server specifies its abstract security policy using the OrBAC API. This policy describes permissions to execute the different workflow tasks. So, the set of assignment is translated to the following abstract security policy (SP): SP = {R 1, R 2, R 3, R 4, R 5, R 6, R 7, R 8, R 9, R 10 }

133 5.5 Case study: telesurgery 119 Figure 5.6: A simple workflow of a telesurgery operation

134 120 Deploying security policy in intra and inter WFMS R 1 = (permission, Strasbourg hospital, surgeon, T 1, surgical console, default) R 2 = (permission, Strasbourg hospital, surgeon, T 2, surgical console, default) R 3 = (permission, Strasbourg hospital, surgeon, T 3, surgical console, default) R 4 = (permission, robotic team, robot, T 4, robot s arms, default) R 5 = (permission, robotic team, technician, T 5, robot s arms, bleeding ) R 6 = (permission, robotic team, anaesthetist, T 6, patient, R.A ) R 7 = (permission, medical team, assistant, T 7, video display terminal, default) R 8 = (permission, medical team, assistant, T 8, medical record, N.R.A ) R 9 = (permission, medical team, assistant, T 9, medical record, default) R 10 = (permission, medical team, assistant, T 10, video display terminal, default) In this policy we use the context default when there is no condition to satisfy when executing the task. Also, we suppose in this case that the same subject executing the task T 7 must execute the task T 6 (same subject(t 6, T 7 )). We notice that the Task T 6 is executed within the sub-organization robotic team and the Task T 7 is executed within the sub-organization medical team. The order of execution of different tasks is represented in figure 5.6. When the process enactment engine receives the workflow specification it starts its user-role assignment for the execution of the workflow. In the following, we define subjects that we assign to different roles: empower(strasbourg hospital, John, surgeon) empower(robotic team, OurRobot, robot) empower(robotic team, Alice, anaesthetist) empower(medical team, Alice, assistant) The PEP of the IWFC communicates with the PDP of the policy server to tell him about the assignment that it has done. Combining this assignment with the abstract security policy stored into the Policy Repository, the PIE generates the concrete policy. This policy contains security rules defined with a default context, i.e. the set of permissions to execute the workflow under normal and usual circumstances. This security policy is defined as a set of concrete rules: SP = {R 1, R 2, R 3, R 4, R 7, R 8, R 10 }

135 5.5 Case study: telesurgery 121 R 1 = (permission, Strasbourg hospital, John, T 1, surgical console, default) R 2 = (permission, Strasbourg hospital, John, T 2, surgical console, default) R 3 = (permission, Strasbourg hospital, John, T 3, surgical console, default) R 4 = (permission, robotic team, OurRobot, T 4, robot s arms, default) R 7 = (permission, medical team, Alice, T 7, video display terminal, default) R 8 = (permission, medical team, Alice, T 8, medical record, N.R.A ) R 10 = (permission, medical team, Alice, T 10, video display terminal, default) This security policy is managed by the IWFC. When the execution of the workflow starts, each WFC must require the permissions to execute its different activities. This request is done at the execution of each task of the workflow. Let us suppose that during the execution of the workflow the context R.A is activated. In this case, the IWFC is informed of this new event within the workflow. This entity must communicate with the PDP of the server of the security policy. To generate the rule associated with this event the PIE activates the abstract rule R 6 defined under this context and other rules of permitted activities related to this condition. It generates the following concrete rules R 6 with the active context R.A and the rule R 9. These rules are sent to the IWFC s PEP. It will relay them to the appropriate organization. R 6 = (permission, robotic team, Alice, T 6, patient, R.A ) R 9 = (permission, medical team, Alice, T 9, medical record, default) We can notice that the rule R 6 implies an information flow control that the IWFC has to manage. The subject Alice acting on the medical team has to move to the robotic team when the context R.A is activated. This subject has the role assistant in the medical team organization and the role of anaesthetist in the robotic team sub organization. The IWFC defines an information flow security rule to manage this transition as explained in section If we suppose that, to access this organization, Alice has to clock in we can express this rule as follow: SR = (permission, VO, medical team, Enter, robotic team, (clock in, (reanimate, patient), coming from(medical team))). This rule says that Alice will have only the permission to reanimate the patient, when she moves to the robotic team. We have discussed this case study in [ACBC09b].

136 122 Deploying security policy in intra and inter WFMS 5.6 Conclusion Several works have investigated security in WFMS since these systems present special requirements of access and information flow control. They are characterized by a diversity of tasks, roles, subjects and objects. But once the workflow security policy is defined and specified, the workflow manager has to know how to deploy such a policy. In this chapter, we address this new issue of deploying a workflow security policy. We present different approaches and modes to administrate the functional and security parts of a workflow. Then, we introduce an approach to deploy the workflow security policy, once it is defined and specified. This management is studied for two different cases: intra and inter organizational workflows. For the intra organizational case we have defined functionalities that different entities (WFC, PEP and PDP) must manage. This case is implemented through calls to the OrBAC API which is responsible for defining the workflow security policy. For the second case a more rigorous control is needed since communications between different and independent organizations are required. Thus, a virtual organization must be created to control the synchronization and the communication between different organizations. The VO is responsible for ensuring the non violation of workflow constraints and managing the transition between domains of workflow subjects. In both cases, the security policy is based on the OrBAC model to specify the workflow security policy. In this work we assume that organizations involved in the workflow belong to some trust alliance that provides some degree of confidence between all parts of an inter-organizational workflow. If a trust alliance does not exist we have to resort to a trust server who will be responsible for controlling the whole workflow execution.

137 Chapter 6 Implementation 6.1 Introduction In the previous chapters, we have been interested in studying security within WFMS and how to manage security policies in order to secure the workflow execution. We have studied the modeling of these systems and we have suggested and analyzed the specification and deployment of security policies within these systems taking into account access and information flow controls. In this chapter we show how we can integrate these security aspects within WFMS and how they can be implemented. To do so, we need a modeling and orchestration tool to represent workflows. This is the topic of section 6.2. In section 6.3, we will describe the MotOrBAC prototype and the OrBAC API. Using this prototype, the security policy is specified using the OrBAC model as previously shown in chapter 3. Then we show how the OrBAC API can be used to progammatically create OrBAC policies. When this API is integrated into the orchestration tool, it controls the workflow execution. In section 6.6 we show how this integration is done in order to define secure workflows. It is based on two parts. First, changes are made on the SFW (Security FrameWork) specification, which is a component of the Tempo tool, in order to manage the security requirements by a more dynamic model. Second, extension of of OrBAC contexts is done to take into account different WFMS constraints that can be defined within the workflow specification. Section 6.7 concludes this chapter. 6.2 Workflow orchestration Existing tools As WFMS consists of a set of tasks executed by different agents, these agents have in practise to communicate since they depend on each other. This communication

138 124 Implementation implies two viewpoints: orchestration and choreography. The orchestration imposes a specific order and also an execution timing on different workflow agents. As a matter of fact, different workflow processes depend on each other and they can use the outputs of each other in order to produce the expected desired result. The orchestration case is similar to a musical director who imposes order and timing individually on a set of musicians and their outputs to produce the expected musical result. Variations and errors in the musicians outputs are frowned upon by the director but do not change the order or timing of the process. By contrast, choreography is a more complicated case and it defines behaviors for handling varied and unpredictable interactions between different workflow agents. In this case, variations and errors in the execution of a process (task) within the workflow can cause changes in the behavior of other task executions. In this chapter we illustrate the work done in different previous chapters using existing tools. Different approaches already presented in this thesis do not depend on the scheduling of the workflow. Thus, they can be applied either in the case of orchestration or also in the case of choreography. In this chapter, we consider the orchestration case. The choreography case is considered as a perspective. To deal with the security in this later case, we need appropriate tools and implementations which define an adequate orchestration module offering us the possibility to integrate security requirements. Since these tools are not yet existing, we are limited in the scope of this chapter to the orchestration case. During our investigation, we have noticed that different prototypes developed in order to manage the workflow orchestration are web services oriented. Indeed, different existing technologies are based on web services standards. We have intended to use an existing workflow tool that takes into account different kinds of workflows, including both automated and human being tasks, and going beyond web services business processes. The objective is to integrate the security controls we defined in the previous chapters without having to develop from scratch a workflow tool. We conclude after our investigations of academic prototypes and market tools that there is no existing tool integrating an orchestration module able to manage different workflow processes. For these reasons, our implementation is based on a tool which is more web services oriented. We recall that web services are considered as a particular case of WFMS. In fact, they represent a set of tasks (processes or services) who interact with each other. These processes may also exchange messages during their execution. With the emerging of web services technologies, many languages have been developed to be used to communicate different services and integrate disparate applications and systems using XML-based standards. In parallel to this need, there is a standard approach to connect these different web services to build more meaningful and more interesting business processes. The language the most used within web ser-

139 6.2 Workflow orchestration 125 vices is BPEL (Business Process Execution Language). It is an XML representation which is used within SOA architecture. BPEL organizes different communications between different applications of the SOA architecture. BPEL uses the language WSDL (Web Service Description Language) to describe actions of a process. This language provides all information required to interact with a network service (protocol, service address,...). BPEL is not very efficient to be used in complicated case of orchestration since it has a long execution time. We notice that within SOA architecture a very diversity in languages is used (SOAP, WSDL, BPEL, UDDI,...). Since BPEL is an execution language, which makes it too detailed and technical to be used by business analysts to capture or design business processes, there is a simpler notation which can be used to design the process namely BPMN (Business Process Modeling Notation). The difference between BPMN and BPEL is that the first is used when designing and improving the business process, whereas the second is used when implementing it. The BPMN representation is not too far from Petri net representation since it can represent different execution modes of two activities. In literature, there is no tool which is based on Petri nets when designing the process and defines an orchestration module to manage the process. However, several Petri net based modeling and simulation tools exist. Thus, in this chapter we will use the BPMN to design the workflow. Indeed, the orchestration tool that we will use in this chapter is based on BPMN representation. In table 6.1 we give a short description of some tools that can be used for the web services orchestration. We notice that Microsoft BizTalk Server is more oriented to industrial applications. Thus, in our case, it will not be very useful to use it to illustrate different ideas that we have presented in this thesis. Even if it ensures different flow coordination, Collaxa server will not be used in this chapter as an orchestration tool since it is not free. In the sequel of this chapter, we have chosen to work with Intalio tool for the following reasons: 1. This tool, as we will see in the remainder, is modular. Its modular architecture will allow us to easily integrate our security controls during processes orchestration. 2. It is a complete tool since it provides not only the designer of business processes but also the whole orchestration module and a set of run components to ensure the design, deployment and execution of different processes. Thus, it is a good candidate workflow existing tool to integrate a greater part of the security requirements we defined in the previous chapters. 3. This tool is open source. So, we can develop and integrate in this tool more code related to security requirements. 4. This product already takes into account some security aspects so it will be

140 126 Implementation Tool Microsoft BizTalk Server [MBS] Collaxa Orchestration Server [COS] IBM BPWS4J [IBM] Intalio [int] Description It can be used to design, build, and execute dynamic business interactions within organizations using an orchestration engine. This server supports the XLANG specification. It provides integration of collaborative business processes. It supports the BPEL4WS. Processes in Collaxa are modeled as BPEL scenario. The orchestration server handles asynchronous processes and provides flow and transaction coordination. It is the only product that provides a graphic tool for creating BPEL4WS documents The runtime engine for BPWS4J can be deployed on either Apache Tomcat or IBM WebSphere. It provides a complete Business Process Management System (BPMS) for managing discrete and transactional business processes. Table 6.1: Orchestration Web services tools easier to act on the security module that this tool offers in order to handle our security approach. The remainder of this section goes in more detailed description of this tool in order to show how we integrate the security policy management Intalio designer Intalio BPMS is a complete open source Business Process Management Suite to design and execute business processes. This product provides a designer (Intalio BPMS designer) to allow users to model and simply implement business processes. The implementation of this modeling tool is based on latest Eclipse technologies. Intalio BPMS is built around the BPMN (Business Process Modeling Notation) modeler. Figure 6.1 shows different shapes that can be used when modeling the process. We notice that there are shapes to take into account the AND and OR patterns in the case of a workflow. The use of this palette is easy and very useful. Different automatic possibilities and choices are proposed when creating the business process. It also provides the possibility to associate a file with a task. For

141 6.2 Workflow orchestration 127 example we can associate a word file with a task T 4 which describes different requirements to execute this task. Compared to our Petri net model, this representation does not represent states. In a Petri net, we have places and transitions. With BPMN representation we have only tasks. These tasks can be sometimes viewed as conditions but it will be represented using the same shape. Intalio designer can also offer working with Xform and xsdl files in addition to bpmn files. In our case, we are interested in bpmn files to represent business processes. These files will be then used to simulate the execution of the workflow once the security policy is integrated. Figure 6.1: BPMN Palette Figure 6.2 represents the Intalio user interface. This is the interface used to model the business process. In the following we describe the different functions offered by this interface:

142 128 Implementation 1. The zone gathering all the functions to be used to design BPMN business process. We notice in this part that there are different colors to specify different pools. A pool should clearly identify a participant in the process. These different pools can communicate between each other. There are connections between tasks belonging to these pools. 2. The Intalio palette defined in figure A floating menu allowing the user to simply pick the next task without going back to the palette. 4. The properties tab: these properties can be related to the execution or to the representation of the business process. Useful information that we can introduce using this tab is the assignment of users to different roles. This is represented in figure The tasks tab: process tasks are listed and described. These tasks represent different actions within the process or the workflow. They are atomic and represented by a rectangle in BPMN representation. These tasks correspond to activities in our Petri net model. They are associated with places. So each place in the Petri net or each rectangle in the BPMN description represents an instantiation of an activity as defined in OrBAC concepts. Using BPMN representation, we have a specific shape to represent a looping task. The difference with a Petri net representation is that execution conditions are also considered specific tasks and represented using the same shape. In a Petri net representation, they are associated with different transitions of the model. However, in this type of task, that we can describe as passive, the properties tab of assigning users to a role do not exist. 6. The outline tab that gives the global scheme of the business process and can be used to zoom into a special part of this scheme. 7. Process explorer tab which gives different hierarchies of the project files. 8. The problem tab deals with different errors and warning that can be generated during the business process definition. 9. The Mapper tab allows one to manipulate data thanks to XPath 2.0 functions. Managing the data is critical when implementing a process. Indeed one needs to define the business data that is sent to the process, map it to the different services invoked by the process and use it to define business rules. The workflow representation is done using the Intalio designer. To represent an inter-organizational workflow, each workflow of an organization can be considered

143 6.2 Workflow orchestration 129 Figure 6.2: Intalio user interface and represented as a sub process in the BPMN representation. To execute and orchestrate the process, Intalio designer is based on an implementation of a component which supports the execution and the deployment of the represented process. So, with the Intalio designer interface we need its run tool. This tool is named Tempo. Next section deals with this orchestration engine Intalio Workflow Tempo The Intalio implementation is based on Tempo [tem]. Tempo is a set of runtime components that support workflows within a service-oriented architecture. Tempo is highly modular and so very flexible to integrate different developers needs. It defines a general architecture shown in figure 6.4. We notice in this figure that the tool communicates directly with a user interface. Also, as previously said, the workflow designer is based on the graphical interface defined by Intalio designer. In the architecture we can notice the use of a task object model. It is used to gather different task properties in a common package that can be reused in other components. Besides, Tempo takes into account the access control policy. This service is ensured only by the authentication user when accessing the application.

144 130 Implementation Figure 6.3: User role assignment Besides, Tempo gives a very concise specification for a Security Framework (SFW) to further focus on security requirements. This framework specifies only the model to be used for this purpose, namely the RBAC model. This proposition can not be very useful since the RBAC model, as explained in previous chapters, has a static approach to define an access control policy. In this work, we change this specification by using the OrBAC model instead of the RBAC model. Tempo is composed of many components which have to communicate between each other to be able to ensure a correct execution process. An overview of these components is given in table 6.2. A communication diagram between these different components is presented in figure 6.5. The diagram is essentially composed of two parts. The first part concerns the start of the task execution by sending a create task request from the UBP component. If the response is received, the task is executed by the TMS component. The second part concerns the accomplishment of task execution. The TMP component supervises the execution state of different tasks. In our work, we use Intalio designer to represent the workflow application and we use Tempo as its orchestration tool. The components that will be useful for us are the TMS, UI-FW, TMP and SFW. In the definition of SFW, only a simple specification is defined to show how the access control will be taken into account. This specification is based on the RBAC model. It is defined as an XML file statically describing different permissions to use during the process deployment. As already explained, such a specification can not be adequate to define workflow processes. It could not take into account different circumstances and constraints that can be defined with

145 6.2 Workflow orchestration 131 Component UBP FDS TMP TMS UI-FW XFM WDS TAS SFW TOM Description User Business Process. That s the process that creates the task. It is typically a BPEL process, but in fact it could be any application. It makes a web service call to create the task, and provides a web service operation to complete the task. The Form Dispatcher Service defines a mapping between user-process message and task-management process message representations. The Task Management Processes support the life cycle of workflow tasks from the moment a task is created till it is completed. It is responsible for changing task states according to rules and user interactions as defined in the process. Task Management Services. It is a web service providing the workflow actions, saving tasks in the database and handling security (through the Security Framework, not shown in the diagram) The User Interface Framework is the web application that gives users access to workflow functionality. It provides the login screen and task list. Is it responsible for serving the appropriate interface when the user selects a task. The XForms Manager is responsible for rendering XForms code and providing workflow actions for such forms. The Workflow Deployment Service allows design-time and automation tools to remotely deploy task descriptions and form content. The Task Attachment Service is a service that ensures different attachments linked to tasks. The Security FrameWork is used by the User Interface Framework for authenticating users at login and by the Task Management Service for authorizing any TMS call. Different implementation of this interface can be plugged in Tempo in order to integrate with various security systems. The Task Object Model is a data-access layer to create, query and manage task definitions and task instances. It defines the task properties in a common package that is reused in other components. Table 6.2: Tempo components

146 132 Implementation Figure 6.4: Global Tempo architecture the workflow specification. The SFW specification defines three subsystems using the RBAC model: 1. RBACAdmin: Administrative services for the creation and maintenance of RBAC element sets and relations. This is used to add/delete users, assign a user to a role, delete the assignment of a user to a role, grant/revoke a role the permission to perform an operation on an object, define role hierarchies, establish/delete a new/an existing immediate inheritance relationship between existing roles, Create a new role and inserts it in the role hierarchy as an immediate ascendant/descendant of an existing role, Set properties assigned to a user / to a role. 2. RBACQuery: Query services for reviewing RBAC element sets, properties and relations. Mainly, find set of users assigned to a given role, set of roles assigned to a given user, the set of permissions a given user gets through his/her assigned roles, the set of the active roles associated with a session, the set of the permissions assigned to the active roles of a session, the set of operations a given role/user is permitted to perform on a given object, the set of ascendant/descendant roles for a given role, the set of properties assigned to a user/role. 3. RBACRuntime: Runtime services for making access control decisions. With this interface, we check the access for a given user, and the associated roles,

147 6.2 Workflow orchestration 133 Figure 6.5: General Tempo diagram to a given operation on a given object. This RBAC interface has no efficient aspects to take into account different contextual requirements of the workflow specification. When using Tempo in its actual version, these RBAC services do not exist. The process execution does not depend on the security policy that we can specify using RBAC. It only ensures the user authentication by the login using the CAS server. Thus, in this work, we try to make the process execution secure using a specific security policy defined according to the workflow. We choose to replace the use of the RBAC model in this interface by the OrBAC model. In chapter 4 we have specified the security policy to be used within the workflow using this model. So we make use of the Intalio designer to represent

148 134 Implementation the workflow process and of the Tempo components (especially TMP and TMS) to orchestrate different workflow tasks. However, the security part of the workflow will be based on the MotOrBAC tool. Next section introduces this prototype and shows its advantages to be used. 6.3 MotOrBAC and OrBAC API To specify the security policy based on OrBAC, a prototype called MotOrBAC has been implemented by the security team (seres: Sécurité des réseaux et des applications réparties ) of Telecom Bretagne. This tool has a graphical interface which allows the user to manage its different entities defined in order to specify the security policy (organizations, roles, activities, views, contexts). The architecture and specification of the MotOrBAC implementation are presented in [ACCC08]. MotOrBAC uses the OrBAC application programming interface (API) to manage the policies displayed in the graphical user interface (GUI). MotOrBAC provides many functionalities to the administrator: 1. Edit policies: the administrator can create the abstract entities needed and the abstract security policies. He can also specify different relations (separation of constraints and hierarchies) between these entities. When editing the security policy, the administrator has to integrate different contexts specified within the security rule. Thus, the abstract security rules are contextual. This abstract policy will then be used to generate different concrete rules. Several concrete rules can be generated from the same abstract rule. They will be an instantiation of this rule using different concrete entities. 2. Policy simulation: once the abstract entities are specified, concrete policy can be inferred using the Jena engine. The MotOrBAC interface allows the simulation of the concrete security policy. Different concrete entities (subject, object, action) are assigned to different abstract entities and so the associated security rules are derived. Concrete entities are represented as objects being instances of classes. Each instance has an identifier and a list of attributes and values. The simulation interface of MotOrBAC shows the set of these rules and it distinguishes rules having an active context from those having an inactive context. Contexts actually implemented in MotOrBAC are: temporal contexts, prerequisite contexts and user defined contexts (contexts which definitions are set to true or false) 3. Policy consistency verification: it allows the checking of different possible conflicts. Since the OrBAC model allows the use of both positive and negative rules (permissions and prohibitions) and even the use of obligation, a conflict

149 6.3 MotOrBAC and OrBAC API 135 between different entities can arise. This conflict can be due to the definition of both a permission and a prohibition for the same role on the same object. In the case of an effective conflict, priorities are used. Indeed, priorities are associated with OrBAC rules. These priorities are used to resolve different conflicts. Rules having a higher priority are prior than those having less priority. Generally in the case when conflict is due to obligations and prohibitions, obligations have priority compared to prohibitions. As a matter of fact, this type of rules (obligation) is especially defined to control the use of the system. Obligations are especially used in case of violation of a system constraint or of a system access. In these cases, the application of the obligation is urgent and so they have to be prior than prohibitions defined for the same role and on the same objects. 4. Resolving conflicts: after detecting different conflicts present in the security policy, MotOrBAC suggests different approaches to resolve these conflicts. The security policy administrator has the possibility to add a separation constraint between entities of conflicting rules. He/she can also modify the priorities between rules when processing a conflict. Another possibility is to change the conflicting rules by other rules. The administrator can also ignore the conflict if he/she consider that the conflict do not have an important impact on the consistency of the security policy and on security requirements of the application. These different approaches are detailed in [CCBG07]. When all conflicts are resolved, the security policy is considered consistent. 5. Administrative rights management: the OrBAC model has also its administration tool called AdOrBAC [CM03a]. This administrative model has been designed to express an administration policy using the same concepts introduced in the OrBAC model. AdOrBAC is integrated in MotOrBAC as an implemented function. Figure 6.6: MotOrBAC architecture

150 136 Implementation The communication between the MotOrBAC GUI and the OrBAC API is described in figure 6.6. The API uses the Jena Java library to represent an OrBAC policy as a RDF graph. It can be used to load MotOrBAC RDF policies and interpret them. When interrogated, the OrBAC API makes decision and response to the request according to the abstract security policy defined and the derived concrete security policy. Jena features an inference engine which is used by the OrBAC API to infer the concrete policies and the conflicts. When an OrBAC RDF policy is loaded by the API, the concrete policy can be inferred and stored in memory. An instance of the OrBACPolicy Java class which encapsulates an OrBAC policy uses a cache of concrete security rules to enhance the performances when the policy is queried. Contexts are evaluated upon a query. This feature is actually used in the MotOrBAC simulation tool to show the contexts state. The context notion is required in order to make dynamic the specified security policy. 6.4 Integration approach To integrate security aspects within the workflow orchestration tool we are based on the MotOrBAC tool, especially on the OrBAC API. Integrating the OrBAC Java API into a Java application can be done without modifying the application source code. The OrBAC API is defined as a plug in. So, it can be easily called. Aspect Oriented Programming (AOP) can be used to separate security concerns from other concerns related to the application. The use of OrBAC API ensures us a dynamic security policy. Indeed, as we have seen, the design and orchestration tool Intalio/Tempo can not express different workflow process constraints. It only designs and orchestrates different process tasks. So, these constraints will be taken into account in the security policy as we have specified in chapter 4. The use of the OrBAC API to integrate security aspects within Tempo architecture, which is modular, is adequate. In fact, the OrBAC contexts implementation can be easily extended in order to interface the API with other applications and add new types of contexts. So, it is adequate to use a WFMS context library in order to integrate specific contexts of the WFMS environment. This library allows us to integrate different workflow constraints when specifying the security policy. The process execution as it is defined now in Intalio/Tempo is not secure. There is no access or flow control on different executed tasks. With the use of the OrBAC API we try to make secure the process execution. Hence, after the design of the workflow using the Intalio interface, the administrator of the security policy has to specify the security policy associated to the process. When executing the process and during its orchestration the Tempo tool has to communicate with the OrBAC API to make decision on different tasks that will be executed in the process. In next section we describe how this integration of security requirements is done.

151 6.5 Secured workflows Secured workflows In this section we show how we can apply different security aspects within the workflow execution. To do so, we use the OrBAC API to specify the security policy associated with the workflow. Then, during process execution, requests will be sent to interrogate the API in order to get the decision made according to the security policy associated with the process. Thus, we can satisfy the security requirements of the workflow specification and control the execution of different tasks. As we have already mentioned, the process modeling and orchestration is done through Intalio/Tempo prototype Integrating OrBAC policy to secure workflow execution First of all, we start by giving the whole architecture to use in order to control the execution of the business process. Figure 6.7 shows different components that will communicate to satisfy the security of the business process. The figure represents the components that will be used in Tempo. We have the UI-FW which communicates with TMS and TMP components for the execution and orchestration of process tasks. When orchestrating tasks the TMS has to communicate with the SFW component. We notice that since the OrBAC API is defined as a plugin, the source code of the workflow modeling and the orchestration of the business process will not change a lot. Using the modular aspect of Tempo architecture, we identify modules to change in order to make calls to the OrBAC API. These calls are integrated into the SFW component. The security part of this component is changed in our case by functions to ensure calls to the OrBAC API which is responsible for controlling the access. Thus, as shown in figure 6.7 we define a communication between the SFW interface and the OrBAC API. In the sequel we detail this communication. Once the administrator has specified its security policy associated with the business process using the MotOrBAC interface, the security policy will be saved into an RDF file. Then, the administrator has to initiate the business process from the Intalio interface. The modeling of the business process is done through the Intalio user interface. Then, to deploy the business process, access control must be enforced. For this purpose, the SFW communicates with the TMS and TMP components to ensure the security of the application. To establish the communication between the SFW and the OrBAC API, several changes have to be made on the SFW component. We replace different existing modules specifications by the implementation of a PEP (Policy Enforcement Point) defined in the SFW component. This logical entity is responsible for querying about the security policy of the business process. Indeed, during the business process deployment, when an access to execute a task is required, a call to the OrBAC API is done by this entity. This call is integrated within the

152 138 Implementation Figure 6.7: Complete Architecture program using AspectJ programming. Since Tempo is implemented in Java, the use of this programming language is adequate in our case, it will not change a lot the source code. The basic program is based on invoking methods already implemented within the OrBAC API. These methods have to check if the access needed is allowed or not. The PEP implementation is based on the following modules: 1. OrBACAdmin: this module deals with the administration functionalities of a security policy. Since the OrBAC model defines its administration tool AdOr- BAC, this module integrates these different functionalities. It is more complete than RBACAdmin since it addresses different administration functionalities and differs from it by not taking into account the assignement/revocation of users and permissions to different roles. This is done during the specification of the security policy by the administrator using MotOrBAC. 2. OrBACRuntime: it invokes methods defined in the OrBAC API in order to check if the access of a user to execute a task is allowed or not. The OrBAC API defines the following three methods to be invoked:

153 6.5 Secured workflows 139 is permited() is prohibited() is obliged() These methods are defined to be used in the case of an open policy (all which is not prohibited is permitted) or a closed policy (all which is not permitted is prohibited) or even a mixed policy (which contains both permissions and prohibitions). This module uses the method checkaccess(string subject, String action, String object). Thus, the PEP communicates with the PDP (Policy Decision Point) implemented within the OrBAC API. The PEP ends a request to the PDP and it sends the concrete triple (subject, action, object) to the PDP through the OrBACRuntime module using the checkaccess method. The PDP receives these concrete entities. Then, it explores permissions or/and prohibitions related to these entities in the set of concrete rules already derived from the set of abstract rules during the phase of security policy specification. Once the needed rule is found, the PDP decides about the PEP query. To take an access right decision the PDP needs to know if the context status is active or not. So, it asks for the information by sending a request to the PEP. When the response is received, the PDP evaluates the rule. Then, the PDP responses to the PEP query by a boolean value indicating if the required access is permitted or not. We notice that the implementation of the PEP does not need a module for user/role and role/permission assignments as it was defined initially in SFW. Indeed, this assignment is already done through the derivation of the set of security rules when the security policy was specified using the MotOrBAC tool. The diagram of figure 6.8 represents the communication part to ensure the security of the business process. First, we represent the user authentication. The UI-FW sends an authentication request to the SFW component. A response to the request is then sent. The user is authenticated. When the execution of process tasks starts, the TMS sends a request to the SFW for authorizing any TMS call. Before the task execution, a request is sent to the SFW in order to know if the subject is authorized to execute the task using a specific object. This request has as arguments a triple (subject, action, object). The request is then forwarded from the SFW component to the OrBAC API. The API controls if there is, in the file where the security policy is saved, an active security rule which corresponds to this triple. This control is done in the set of concrete rules and also in the set of abstract rules. For the abstract rules, we control if there is a rule that we can use to derive a concrete rule corresponding to the received triple. Since rules are contextual, we can find a rule corresponding to the received triple but defined with a specific context. In this case, the OrBAC API has to know the status of this context within the application.

154 140 Implementation Figure 6.8: Security communication diagram Hence, the PDP asks about the context status then sends its decision depending on the security rule. The implementation of the OrBAC API as it is defined now does not take into account contexts that can be specific to workflows. In the next section, we present how we define an extension of the context implementation in order to take into account different contexts related to workflows Extending OrBAC contexts As we have mentioned in chapter 4, WFMS need specific contexts to take into account different workflow constraints (see section 4.3). To deal with these different constraints, we extend OrBAC contexts to include WFMS contexts. This extension is done through the IOrBACManagement interface. The class implementing this interface (COrBACContextManager) is responsible for managing the contexts defined in a policy. The interface specification suggests using factories to create the contexts objects. In java, the use of factories to create different objects is useful since it makes the implementation more generic. Such factories can be dynamically added during runtime to the context manager instance through a call to the Add- ContextFactory method. The COrbacContextManager implementation uses a set of context factories which implement the IOrbacContextFactory interface. Each context factory is associated with a context type. Actually when a context is created in a COrbacPolicy instance, the context name and type must be given. The context type is used to search for a corresponding context factory. The default context manager implementation used in a COrbacPolicy instance can be replaced by another implementation through a call to the SetContextManager method.

155 6.5 Secured workflows 141 Adding a new type of context consists in implementing a class inheriting from the CContext abstract class and implementing the corresponding factory. For WFMS, we define the CWfmsContext class to include WFMS specific contexts. Several methods must be implemented to specify the context behaviour. We only list here the most important methods that must be implemented: 1. GetType(): this method returns the context type as a String object. The string is used in the RDF graph managed by a COrbacPolicy instance to record the context and its definitions. 2. GetState(String org, String subject, String action, String object): this method returns the context state for the given triple subject, action, object in organization org. In the case where the OrBAC API will be called by an external application like in our case with Tempo tool, the communication will be made between the interface of the application (in our case with SFW component) and the CWfmsContext class. In the method GetState(), we have to know if the context status is active or not. To get this piece of information, the method GetState() must interrogate the application interface. This later will transfer the information about the actual context status to the OrBAC API. Knowing different elements of the security rule, the OrBAC API derives the decision about the permission needed and sends the response about the permission request to the application interface. Once the new context type is implemented, we must implement its associated context factory. Afterwards, the new context type is added to the COrbacPolicy instance. The extension of OrBAC contexts is based on the set of constraints defined in chapter 4. As specified in section , different workflow constraints will be defined using the OrBAC contexts. In the current version of MotOrBAC, the implemented contexts are: 1. Temporal contexts: we extend the CTemporal context class to take into account different temporal execution constraints. As it is implemented, this context only specifies different execution interval of a task. It does not deal with different execution modes. So, we define different temporal modes relating different tasks of a process. 2. Prerequisite contexts: we extend CPrerequisiteContext to take into account the Binding of duty constraint. In this class, we define the specific predicates same subject and same role to express binding of duty. We define a new context class called CHistoryContext to deal will different history constraints that depend on previous task execution. This type of context needs

156 142 Implementation Figure 6.9: Contexts implementation a communication between the application and the OrBAC API. To be able to create an execution history, the TMP component has to sent the execution result to the SFW component. The PEP implemented in this component sends information request to inform the PDP about the result of different tasks executions. These results are saved into a file which is then used to evaluate history constraints. Thus, when a task depends on the execution of another task, the PEP sends a request to the PDP. The PDP, when searching for the security rule associated with the request, it will be obliged to search in the history file to check if the context of this rule is activated and valid or not. New contexts can be added into a policy edited by MotOrBAC using a plug-in. Thus, the source code will not be changed. In fact a plug-in can modify a context manager of a policy. For example, when the plug-in associated to the CWfmsContext is activated, the policy manager will have the possibility to define contexts related to workflows. If the application do not need this type of contexts, the plug-in can be deactivated.

157 6.6 Discussion Discussion In this chapter, we tried to show how we can integrate access control requirements during a process execution. We have seen that the functional part of process modeling is not changed. This is due on the one hand to the modular aspect of Tempo and on the other hand to the OrBAC API which is implemented as a plugin. The integration of information flow security rules is not developed in this chapter. The specification of the integration of information flow rules as specified in chapter 4 is modeled with Petri net. These rules are associated with different transitions of the model. The BPMN representation does not represent transitions. The firing of transitions is normally related to the activation of these rules. These rules are added to the OrBAC API. When the call to the API is done, the request provides the source and destination domains, i.e the two roles concerned by the transition. Then, the OrBAC API answers by the rule ensuring this transition. This rule contains the entry point to be executed in order to make the transition valid. This communication is represented in figure 6.10 where steps are defined in the following: 1. Constraint msg(d i, D j ): it is a message sent from the PEP to the PDP indicating the source and the destination domains concerned by the transition. 2. EntryPoint msg(e i,j ): a message sent from the PDP to the PEP containing the associated entry point to the transition between the domains D i and D j. 3. ExecutionResult msg: message indicating the result of the execution of the entry point, sent from the PEP to the PDP. 4. Set privileges: the PDP sends the set of privileges assigned to the subject transiting to the destination domain after a successful execution of the entry point. Figure 6.10: Ensuring information flow control In the literature, there are tools of workflows simulation using Petri nets. These simulation tools do not define an orchestration module for workflow tasks. For this

158 144 Implementation Tool Time Predicates Colors Components PN type SEDRIC Yes Yes Yes Simulator Interpreted and colored PN SPN2MGM Yes No No Stochastic PN Simulaworks Yes No No Simulator timed and hybrid PN DiaGen No No No Editor and analyzer General diagrams TINA Yes No No Simulator and editor Temporized PN Jfern Ye No Yes Simulator Temporized PN PNK No No No Simulator/editor/ Basic PN analyzer Renew Yes Yes No Editor and simulator programmable PN SIPN-editor Yes No No Editor Interpreted PN TimeNET 3.0 Yes No Yes Modeling and analyzer Stochastic PN CPN tools No No Yes Editor/analyzer/ Colored PN simulator Table 6.3: Petri net based simulation tools reason, we could not use them to design and then execute the workflow process. Table 6.3 summarizes these different tools and gives their different functionalities that they can express. We indicate if or not these tools are able to express time, predicates and colors within a Petri net representation. We also show the type of the Petri net that these tools can represent and the components that they offer. When using Intalio designer, we have the possibility to express either sequential or concurrent or parallel tasks. These execution modes are represented by the BPMN representation. Synchronization of these tasks is ensured by the Tempo tool when executing the process. When each task has to be executed, a call to the OrBAC API is done. These calls enforce the execution modes of the process. During the policy specification, these execution modes are included and described in the coordination policy. Then, when the PDP makes its decision about the security policy, it will take into account these temporal constraints to activate or not the context. If we suppose for example that two tasks T i and T j have to be started at the same time, when receiving the request for the authorization to execute T i, the PDP activates the context of this rule only when it receives the request for the execution of T j. The context of rules associated with these two tasks becomes active and so the rules can be executed. In this case, the rules associated with the execution of these tasks are obligations as defined and specified in section Then the TMP component is responsible of supervising the execution of these tasks after granting permission of execution.

159 6.7 Conclusion 145 In this chapter, all calls to the OrBAC API are managed through the SFW component. Thus, the approach used to deploy the process is the outsourcing approach. If we want to use a provisioning approach, the communication will be directly defined between the OrBAC API and the TMP. This communication will have a greater execution time. In this case, each task execution needs a call to the OrBAC API, whereas, using outsourcing approach, the communication with the Or- BAC API is ensured through the SFW component which centralizes different calls for the execution of different workflow tasks. Thus its execution time is shorter. 6.7 Conclusion In this chapter, we have been interested in integrating access control requirements within the workflow execution. For this purpose, we have chosen the Intalio/Tempo product as a tool for workflow modeling and orchestration and then we have shown how to use of the OrBAC API defined as a plugin in order to control the business process execution. The modular specification of Tempo tool and the definition as a plug-in of the OrBAC API have made this integration easy. We have seen that the only component that has to be changed is the SFW initially specified to manage the security of business processes. We have changed this specification in order to take into account the dynamism of the business process execution. The new integration of security aspects is adequate since the security policy is instantaneously queried. The decision sent to the SFW interface depends on the execution progress of the business process since the request is done dynamically and during the process execution. New context type is added to the set of OrBAC contexts in order to consider different constraints that can be defined with the process specification as defined in section 4.3 of chapter 4. A communication between the application and the OrBAC API must be maintained to know the context status and/or update it. The integrated security aspects are limited to access control. The information flow control is not integrated in this case since the initial specification done to integrate the flow control within the workflow execution is based on a Petri net based modeling. This choice of modeling is related to the specification of the security policy. Since the security policy is based on the OrBAC model, the modeling of the workflow has to be consistent with concepts defined in the security policy. Besides, the Petri net representation facilitates the functional control of the workflow execution. Actually, Petri net based simulation tools are able to simulate the functional execution of the workflow but they do not define any orchestration module of workflow tasks. However the definition of information flow control rules remains possible within the OrBAC API independently of any application. These new rules are characterized by their specific context managing the transition between different roles. The integration of these rules within the OrBAC API is easy since they preserve the

160 146 Implementation same format and concepts of a usual OrBAC rule.

161 Chapter 7 Conclusion & Perspectives 7.1 Concluding remarks As we have seen, WFMS are known for a diversity of tasks that have to be executed in a coordinated manner, users that must execute these tasks and resources that they have to use in order to achieve their common goal. With this diversity, the security of these systems is a critical issue. In this thesis, we have been interested on the access and information flow controls as an inescapable requirements to ensure the secure execution of different workflows. As a first contribution we have defined an integrated model to express both access and information flow control. This integrated model is based on OrBAC model. To integrate information flow requirements, we have used DTE concepts. Using the entry point concept, we defined how to control the transitions between different organizations or also a change of role in a specific context. Through the context notion defined in OrBAC, the security policy specification takes into account different conditions and constraints that can be defined with the workflow specification. These constraints must not be violated during the workflow execution otherwise the functional and the security aspects of the workflow will be affected. They can be either static or dynamic depending on their time evaluation. Then, this security policy specification is applied to the workflow execution. For this reason, we use Petri nets to model workflow processes. The expressivity of this tool offers them an understandable modeling. The Petri net model is defined based on OrBAC concepts. The security policy specification is associated to the defined Petri net model by assigning different access control rules to places and different information flow control rules to transitions. We have also proposed a decentralized procedure to execute the workflow in a secure manner. This procedure controls the transition firing depending on the specified security rules and the allowed transitions. In the case of a decentralized execution

162 148 Conclusion of the workflow, different agents play a role in ensuring its security. So, a coordination security policy is responsible for ensuring a secure cooperation of these agents. On the other hand, we have studied the complexity of the satisfiability problem of a workflow. This problem consists in checking if a specific assignment of a set of users and roles to different workflow tasks is consistent and do not violate the set of workflow constraints. If we suppose that the set of constraints is consistent, the problem is NP-complete. Checking the consistency of the set of constraints has a polynomial complexity. On a next part, when the security policy is defined and specified, we have been concentrated on the deployment of the security policy during the workflow execution. This deployment depends on the execution mode of the workflow (centralized or distributed) and on the security approach that we apply (outsourcing or provisioning). It also depends on the type of the workflow: intra or inter organizational workflows. We have noticed that the inter-organizational case is more complicated to manage since it introduces the need of managing the transition of different subjects between different organizations in order to satisfy both intra and inter organizational constraints. This need is satisfied by the use of an intermediate entity which is the virtual organization (VO) responsible for ensuring the inter-organizational security of the whole workflow. This virtual organization manages different communications between different organizations. The security policy of the VO deals especially with the information flow control. This policy manages the eventual transitions of subjects from an organization to another one. This transition can be imposed by the inter-organizational set of constraints. As a case study of our deployment approach we have considered the application of telesurgery. This application is considered as an inter-organizational workflow since more than one organization have to participate in the process. In the last part of this thesis, we have shown how we can make use of the OrBAC API in order to integrate security aspects within a business process execution. For this purpose, we have chosen the use of an orchestration tool of business processes. This tool is oriented web services which are considered as an example of workflows. The intalio tool is used for modeling business processes. Then, to execute these processes, the tempo components cooperate to ensure the achievement of the process. During this execution, the API OrBAC is called in order to provide the SFW component the security policy to apply during the process execution. In fact, these calls replace the use of the RBAC defined within SFW modules. This integration is considered easy since it is based on the use of oriented aspect programming. Thus, the initial code of the application will not change a lot. So the modularity of tempo tool and the definition of the OrBAC API as a plug-in make the integration of security aspects within the application simple.

163 7.2 Discussion Discussion The work presented in this thesis tries to remedy to different weaknesses of previous works already explained in chapter 2. First of all, it proposes a new vision of managing the security within workflows. Based on the control access model OrBAC, the specification of the security that we propose defines a dynamic approach presented in chapter 4 to deal with either the access or the information flow control. Previous works do not tackle the issue of the information flow control. They have only tried to define a convergence between access and information flow control. Even this convergence was not well defined since it was based on the RBAC and MLS models. Using a mapping between RBAC roles and MLS clearances they associate a clearance with each role. The misuse of this mapping is explained in section 3.2 of chapter 3. We resolved this misusing by basing the convergence on two different models, OrBAC and DTE. This convergence makes the security policy of the process more coherent. This coherent security policy is applied on the Petri net model that we have proposed. Designing a model that uses OrBAC concepts makes the application of the security policy simple and easier to specify. Models used in previous works are not defined in accordance with the security policy. When these models are based on Petri nets, their associated security policies do not use the same concepts used to define the model. In our case, we have associated semantics to different places and transitions of the model. These semantics are in accordance with the security policy specification. Indeed, different security rules are applied on transitions and places. Thus, the model is expressive enough to let us express different workflow constraints in order to ensure a secure workflow execution. The use of the security policy is defined in a decentralized manner. The approach that we proposed remedies to the static one already presented in different works previously done. In the centralized approach only a central entity has a global view of the workflow and manages functional and security parts of the process. In our case, we consider that all agents of the workflow participate to ensure the security of the workflow. Thus, the orchestration of the workflow is done in a decentralized manner. The procedure of the workflow execution defined in section of chapter 4 shows how privileges are managed according to the execution progress of the process. Besides, different works already presented in section 2.7 of chapter 2 do not show how to deploy the security policy after its specification. We have tackled this issue in chapter 5. We have defined the different approaches that can be used to that effect. We noticed that these works consider a simple case of different workflows. Indeed, they consider a workflow as a set of tasks executed in a sequential order and that all tasks of the workflow are executed within the same organization. In this thesis, we have remedied to these lacks by considering all different execution modes of a task and by taking into account the inter-organizational case.

164 150 Conclusion 7.3 Perspectives The work done in this thesis provides more than one researching issue. Firstly, during a workflow execution and after task user assignments, changes can occur within the system. A user assigned to a task can be not able to accomplish the task because of a specific circumstance. In this case, the administrator system has to find a solution to replace this user. The resiliency in a workflow execution can have many impacts on the workflow execution especially when the change occurred is related to the constraint base. In this case, the workflow becomes more constraining since constraints have to be respected and a set of tasks have been already executed. A possible solution to this problem and which does not affect the coherence and the consistency of the workflow is to delegate the task to another user and controlling this delegation. Many works have been done to propose delegation models [ER00, ZOS03b, RT08, PL05, LPLN04, AMH07, BS04]. These models are based on the RBAC model. Since this model has a set of limitations described throughout this thesis and it has a static approach, a new delegation model has been proposed in [BGTCCBB09]. This model goes far from RBAC limitations since it is based on the OrBAC model. The integration of this delegation model into our workflow model can be an extension of this work. This integration seems natural and coherent since the two models are based on the same access control model OrBAC. This delegation model defines and controls how the delegation will be done and how rights and privileges will be managed. It also defines several types of delegation depending on the requirement of the application. It defines the duration of the privileges assigned after a delegation. In parallel to this delegation model, [BGTCCBB08] proposes a revocation model which specifies the rules of revocation of a delegation. Within a workflow, the control of different privileges during a delegation process is important since different workflow tasks communicate information between each other. The specification of the security policy and the management of delegation and revocation policies are defined by the system administrator. Thus, the definition of the security policy and different activities done on this policy have to be administrated. The work done in [Gho09] deals with decentralized administration. Since our security policy is based on the OrBAC model, we can use its administration tool, namely AdOrBAC, to deal with different administration aspects. In this model, every entity corresponds to an object. Then, the approach used in this administration model is to define administration functions by considering different administrative views. Objects belonging to these views have specific semantics. Secondly, in this thesis, we have investigated the inter-organizational workflows. We have been interested in this case to different exchanges of roles that can occur to satisfy workflow constraints. In this thesis, we have only considered the control of the transition from a role to another role. We do not describe how resources of an

165 7.3 Perspectives 151 organization can be used by a role not belonging to this organization. If within an inter-organizational workflow an interoperability is required, then organizations can need to use resources belonging to other organizations. Thus, our work can be extended by the O2O approach (for Organization to Organization), defined in [Com09]. O2O is based on the OrBAC model and it extends it to control interoperability of organizations managing different security policies. This approach introduces the concept of Virtual Private Organization (VPO) to refer to the sub-organization in charge of the interoperability access control. Since O2O uses the OrBAC formalism, it is possible to extend our WFMS security policy by a policy managing how external subjects may have an access to the current organization. Thirdly, the use of obligations in this work is limited to enforce execution modes of workflow tasks. Obligations can be used even to enforce the system behavior. Besides, obligations can be useful in order to enforce specific workflow constraints like the constraint stating that All reviewers of a conference are obliged to not submit to this conference. Works done in [ERCBC09] are interested in studying the use of obligations using contextual rules. The use of obligations is applied to groups. Thus, [ERCBC09] introduces the notion of group contexts through which the policy designer can choose different interpretations for group relations in obligation security rules enabling him or her to specify obligations representing shared responsibilities such as All patients must be checked by a doctor or obligations expressing sets of alternative actions such as Every customer should pay either in cash or by check. Another perspective is related to the deployment part of this work. In the case of an inter-organizational workflow, we have considered a Virtual Organization which is responsible for managing all communications between different organizations. In this case, we have supposed the notion of trust which exists between different organizations. Thus, these organizations have trust on the VO and they provide it their local information. If we suppose that there are organizations with a high degree of confidentiality and that they can not trust the VO, inter-organizational communications will not be ensured by the VO. In this case, organizations have to negotiate between each other in order to construct some confidence degree and to specify how inter-communications will be ensured. In this negotiation, the type of relation between different organizations is defined and specified. The degree of trust on organizations and on users can depend on the type of information that an organization manages or on the skill and knowledge of different users or on their already achieved tasks (depending on trusted users saying that they can be trusted). For the implementation part, the choreography of a workflow represents a perspective to the work done in this thesis. In chapter 6, we have only considered the orchestration case. The implementation of a choreographical tool will offer us the possibility to deploy different ideas presented in this thesis. Also, implementing an orchestration module to one of Petri net based simulation tools make possible the

166 152 Conclusion simulation and the integration of different access and information flow controls.

167 Appendix A Résumé A.1 Introduction Un workflow peut être défini comme étant un processus composé d un ensemble de tâches devant être exécutées dans un ordre bien déterminé. L ensemble de ces tâches doivent coopérer pour achever un objectif générallement commun. Les WFMS (Workflow Management Sytems) sont les systèmes qui supportent l administration et la gestion des processus en se basant sur des workflows. Ces systèmes sont générallement caractérisés par une diversité des tâches à exécuter, les rôles exécutant ces tâches et les ressources utilisées pour l exécution de ces tâches. Avec toutes ces diversités et ces caractéristiques, le besoin d assurer la sécurité de ces systèmes s impose. Dans le cadre de cette thèse, nous allons nous intéresser à la gestion du contrôle d accès et du contrôle de flux au sein de ces systèmes. D une part, les différents sujets qui vont exécuter les tâches du workflow doivent avoir accès aux différentes resources dont ils ont besoin. L accès à une même ressource par deux sujets différents doit être géré afin que celui ci ne touche pas à l integrité du processus. D une autre part, les sujets exécutant les tâches peuvent être amenés à communiquer entre eux. Ces différentes communications doivent être contrôlées pour éviter tout type de fuite d informations. Le problème devient plus dangereux quand ces sujets maintiennent des informations qui peuvent être confidentielles ou sensibles. Générallement la specification d un workflow définit en plus de l ordre de l exécution des tâches, un ensemble de contraintes qui sont définies par rapport aux tâches, aux sujets et aux rôles exécutant ces tâches. Cet ensemble de contraintes doit être satisfait lors de l exécution du workflow. La violation d une contrainte peut affecter le bon fonctionnement et la sécurité du workflow. Donc, pour satisfaire ces contraintes et contrôler l exécution du workflow, l utilisation de modèles de contrôle d accès s impose. Dans la littérature, il existe plusieurs modèles de

168 154 Résumé contrôle d accès qui ne sont pas tous adéquats pour être utilisés dans le cadre des WFMS. Avec l aspect dynamique qui caractérise ces systèmes, le modèle de contrôle d accès à utiliser doit être suffisamment dynamique pour prendre en considération ces différentes caractérisations. Vu qu on a aussi besoin de prendre en compte le contrôle de flux, nous devons intégrer l expression du contrôle de flux au sein des règles exprimant le contrôle d accès. Le travail réalisé au cours de cette thèse concerne la sécurité des WFMS. Plusieurs travaux ont été réalisés autour de ce sujet mais ces travaux présentent des nombreuses faiblesses. Les contributions de cette thèse sont plus qu une. Tout d abord nous nous interessons à faire ressortir les faiblesses que les travaux précédents présentent. En plus, nous nous définissons une convergence du contrôle d accès et du contrôle de flux afin de satisfaire les besoins de ce type de systèmes. Ainsi, pour avoir une politique de sécurité cohérente nous nous sommes basés sur les mêmes concepts pour exprimer le contrôle d accès et le contrôle de flux. Pour ces raisons, notre politique de sécurité se base sur le modèle de contrôle d accès OrBAC (Organizational Based Acces Control). Ces règles OrBAC sont enrichies par des concepts définis dans le modèle de contrôle de flux DTE (Domain Type Enforcement). L utilisation d une telle convergence est utile et efficace dans le cadre des WFMS. Son avantage est la flexibilité et la dynamicité de la politique qui prendra en compte non seulement le contrôle d accès mais aussi le contrôle de flux. L utilisation de ces règles dynamiques permettera l expression des differentes contraintes qui peuvent être définies avec la specification du workflow. Nous remarquerons que notre approche remedie aux différentes faiblesses présentes dans les travaux déjà faits. Une fois que cette politique de sécurité est bien définie, nous proposons une procédure décentralisée qui est responsable de surveiller l exécution du workflow. Dans cette procédure, tous les agents d un workflow participent pour assurer un environnement sécurisé d exécution du workflow. Dans les travaux réalisés, une entité centrale est définie pour gérer l aspect fonctionnel et l aspect sécurité du workflow. Cette entité doit avoir une vision globale du workflow et c est à elle de s occuper de la synchronisation des différents agents qui n ont aucune connaissance de la totalité du workflow. Pour rendre un workflow plus comprehensible et plus fonctionnel, nous utilisons les réseaux de Petri pour les modéliser. Nous définissons un modèle qui respecte les concepts définis au niveau de la politique de sécurité. Ainsi, correspondre la politique de sécurité au modèle du workflow sera fait d une façon très naturelle et simple. Une autre contribution de cette thèse consiste à l étude du déploiement de la politique de sécurité une fois qu elle est bien spécifiée. Pour cela nous étudions les différentes approches que nous devons adopter pour gérer soit la partie fonctionnelle du workflow ou soit la partie sécurité du workflow. Ce déploiement considère les deux cas intra et inter organizationnel d un workflow. Nous remarquerons que le deuxième

169 A.2 Preliminaires et travaux réalisés 155 cas est beaucoup plus complexe à gérer puisqu il introduit des communications entre les différentes organizations qui doivent être contrôlées. Comme exemple pour ce cas, nous considérons l application d une chirurgie à distance. La thèse est construite comme suit. Le chapitre 2 introduit les différents modèles de contrôle d accès et de contrôle de flux existants et qui peuvent être interessants dans le cadre des WFMS. Ce chapitre résume aussi les différents travaux qui ont été déjà faits autour de la sécurité dans ces WFMS et fait ressortir les différentes faiblesses et manques qu ils présentent. Nous déduisons que le modèle OrBAC est le modèle le plus adéquat à utiliser dans le cadre des WFMS. Nous remarquerons que la sécurité multi-niveau ne peut pas être un bon choix pour ces systèmes. Finalement nous présentons l approche que nous adopterons au cours de cette thèse. Le chapitre 3 propose une convergence entre le contrôle de flux et le contrôle d accès afin d être appliquée au sein des WFMS. Dans le chapitre 4, nous présentons un modèle basé sur les réseaux de Petri pour la modélisation des workflows. En plus, le chapitre définit un environnement sécurisé pour l exécution du workflow. Aussi, nous nous interésserons à étudier la complexité du problème WSP (Workflow Satisfiability Problem). Nous déduisons que ce problème est NP-complet. Le chapitre 5 s interesse à l étude de déploiement de la politique de sécurité en présentant les différentes approches possibles. Dans le chapitre 6, nous montrons comment on pourra intégrer ces besoins de sécurité au niveau d une application. Cette intégration sera basée sur des appels vers l API OrBAC. Pour la modélisation des workflows nous prenons comme exemple l outil Intalio qui est orienté web services, considérés comme étant un cas particulier des WFMS. Finalement, le chapitre 7 conclut ce manuscrit et donne des grandes lignes pour des recherches futures. A.2 Preliminaires et travaux réalisés A.2.1 WFMS et le contrôle d accès Les WFMS se caractérisent par des nombreuses diversités de tâches, de rôles et de ressources qui imposent le besoin de s intéresser à la sécurité de ces systèmes. Dans cette thèse, nous nous intéressons à la gestion du contrôle d accès et de flux au sein de ces systèmes. Dans la littérature plusieurs modèles de contrôle d accès existent. Les modèles traditionnels de contrôle d accès se basent sur trois entités: sujet, action, objet. Une règle de sécurité est ainsi définie comme étant une permission d un sujet pour faire une action sur un objet. Avec une telle définition, les règles de sécurité considérées sont assez statiques et elles ne peuvent pas être adéquates pour exprimer les différents besoins au sein d un workflow. Après ces modèles, il y a eu des tentations pour spécifier des modèles plus expressifs. Ainsi, il y a eu l introduction du modèle RBAC (Role Based Access Control). Ce modèle abstrait la notion de sujet

170 156 Résumé en notion de rôle. Ainsi, un rôle représente un ensemble de sujets sur lequels on peut appliquer le même ensemble de règles de sécurité. Ce modèle a l avantage d être plus générique par rapport aux modèles élémentaires et de réduire le nombre de règles à définir au niveau de la politique de sécurité. Mais même ce modèle reste insuffisant pour pouvoir exprimer l aspet dynamique des workflows. En effet, les règles de sécurité exprimées par ce modèle restent statiques. Après le modèle RBAC, il y a eu l apparition d un modèle beaucoup plus expressif et plus dynamique. Ce modèle est appelé OrBAC (Organizational Based Access Control) [KBB + 03, CNBSM04]. Ce modèle a introduit des nouvelles notions qui se résument générallement en ce qui suit: Abstraction du triplet traditionnel <sujet, action, objet> en un triplet abstrait <role, activité, vue>. Un rôle, une activité et une vue représentent respectivement un ensemble de sujets, actions et objets sur lequels les mêmes règles de sécurité s appliquent. Introduction de la notion de l organisation et la notion du contexte. Ces deux notions sont très intéressantes. Le concept d organisation nous permet d exprimer le confinement au niveau de la politique de sécurité. Ainsi, chaque organisation peut définir sa propre politique de sécurité et la gérer indépendemment de toute politique de sécurité d une autre organisation. Le concept du contexte nous permet d exprimer les différentes conditions ou circonstances qui peuvent rendre la règle active. En d autres termes, au sein de l organisation les règles de sécurité sont définies sous un contexte spécifique. Donc la régle n est vraie que quand son contexte est vrai. Le modèle définit un contexte par défaut à utiliser au cas où la règle est définie sans contexte spécifique. Cette notion rend le contexte OrBAC beaucoup plus flexible et dynamique comparé aux autres modèles. Pour ces raisons, le modèle s apprête bien à être utilisé dans le cadre des WFMS. Introduction de la notion de permissions négatives et d obligations pour exprimer les règles de sécurité. Avec ces différents types de règles, l administrateur aura la possibilité de définir des politiques ouvertes (tout ce qui n est pas interdit est permis) ou fermées (tout ce qui n est pas permis est interdit) ou mixtes (contient des permissions et des interdictions). La figure A.1 représente le schéma général du modèle OrBAC. Une règle OrBAC est définie comme étant un 6-uplet: SR(Type, organisation, rôle, activité, vue, contexte), type {permission, prohibition, obligation}. La spécification de notre politique de sécurité va se baser sur le modèle OrBAC. Ainsi, notre approche va remédier à l aspect statique des travaux qui ont été déjà réalisés. Dans le cadre des WFMS,

171 A.2 Preliminaires et travaux réalisés 157 deux types de contextes sont définis dans OrBAC et qui sont très intéressants. Tout d abord le contexte prérequis qui peut être utilisé pour exprimer les différentes conditions initialement définies avec le workflow. Avec ce type de contextes, nous pouvons exprimer les contraintes de SoD (Separation of Duty). Le contexte temporel [CCB08] nous permet aussi d exprimer les différentes contraintes temporelles pour exprimer par exemple des intervalles de temps bien précis pour l exécution de la tâche. Finalement, le contexte provisionel peut nous servir à exprimer les contraintes des différentes tâches qui dépendent de l exécution des autres tâches. Ce type de contexte peut être considéré comme étant un historique d exécution. Figure A.1: Le modèle OrBAC A.2.2 WFMS et le contrôle de flux Au sein d un workflow, les différents agents exécutant les différentes tâches peuvent communiquer entre eux durant l exécution du processus. Ces communications peuvent impliquer des problèmes de sécurité si les informations échangées ou communiquées sont assez importantes ou voire confidentielles. Aussi, le même sujet peut être amené à exécuter deux tâches différentes en ayant deux rôles différents. Ainsi, ce changement de rôle ne doit pas en aucun cas affecter le bon fonctionnement et l intégrité du processus. Pour ces raisons, la politique de sécurité d un workflow ne doit pas prendre en compte que le contrôle d accès mais aussi elle doit gérer le contrôle de flux entre les différents sujets, soit au sein de la même organisation ou au sein des différentes organisations. Dans la littérature, il existe des modèles de contrôle de flux. Le modèle le plus connu est le modèle basique Bell La Padula (BLP). Ce modèle appartient à l ensemble de modèles de sécurité à multi-niveaux. Ce type de modèles attribut des

172 158 Résumé degrés de confiance aux sujets du système et aussi des degrés de confidentialité aux différents objets du système. Avec ces degrès de confiance, une classification est définie. Le modèle BPL définit deux règles de sécurité qui doivent être appliquées: 1. La propriété de sécurité simple: un sujet ayant un niveau de sécurité ne peut pas lire un objet ayant un niveau de sécurité plus elevé. 2. propriété *: un sujet d un certain niveau de sécurité ne peut pas écrire dans un objet ayant un niveau de sécurité moins elevé. Nous remarquons que le modèle BPL ne définit que deux types d action (lire, écrire) alors que sur un objet on peut avoir des diverses activités. En plus, la première règle que ce modèle définit peut être considéré simple et naturelle alors que la deuxième règle pose un problème. En effet, les niveaux de sécurité sont associés aux utilisateurs alors que ces utilisateurs peuvent être des programmes. Ces programmes peuvent contenir un cheval de troix. En plus de ces faiblesses, les modèles de sécurité multi-niveaux peuvent être considérés assez contraignants. Pour toutes ces raisons, afin de gérer le contrôle de flux au sein des WFMS, nous nous sommes basés sur un modèle beaucoup plus flexible qui est le modèle DTE (Domain Type Enforcement). Le modèle DTE classifie l ensemble des entités actives du système en domaines et l ensemble des entités passives en types. Il se base sur deux matrices. La première matrice (DTE) gère les privilèges qu un domaine peut avoir sur un type. La deuxième matrice définit les différents droits qu un domaine peut avoir sur un autre domaine. Ce modèle sera mieux présenté dans la prochaine section. A.2.3 Etude de l existent Plusieurs travaux ont été réalisés autour de la sécurité des WFMS. Il y a eu des travaux [MM07a, MM07b] qui se sont orientés vers l étude de la sécurité dans des environnements pervasives. Dans ces travaux, aucune infrastructure du workflow est initiallement définie pour le workflow. Ainsi, les agents qui vont exécuter les tâches du workflow seront recherchés au fur et à mesure avec la progression de l exécution du workflow. Dans le travail réalisé dans cette thèse, nous nous ne sommes pas basés sur la même approche. Le workflow considéré est un workflow initialement défini avec l ensemble des agents qui sont authorisés à exécuter les différentes tâches. Par contre l exécution du workflow est considérée décentralisée. Ainsi, tous les agents participent à l aspect fonctionnel et l aspect sécurité du workflow. En plus, ces travaux se sont basés sur la crypthographie pour sécuriser l exécution du workflow. Dans le présent travail, nous gérons la sécurité en se basant sur la spécification de la politique de sécurité associée au workflow.

173 A.2 Preliminaires et travaux réalisés 159 Pour gérer le contrôle d accès dans les WFMS, plusieurs travaux ont été réalisés [AH96, AAH98, HA99, HK99, BFA99, AHB98]. Ces travaux se résument principalement en deux points: 1. La spécification d une politique de sécurité du workflow qui reste statique. 2. La définition d une procédure centralisée pour l exécution du workflow. Ces travaux ne se sont pas interessés à gérer le contrôle de flux au niveau de la politique de sécurité. Néanmoins, il y a eu d autres travaux [NO94, NO96, Osb97, San96, OSM00, SM98, Dem01, Kuh98, AH97, AHB98] qui ont tenté de définir une convergence entre les modèles de contrôle d accès et les modèles de contrôle de flux. Cette convergence est basée principalement sur le modèle RBAC et le modèle BLP. Elle consiste à attribuer des niveaux de sécurité définis dans le modèle BLP aux différents sujets définis pour le modèle RBAC. Cette association ne peut pas être considérée correcte vu que les sujets dans BLP peuvent être des processus ou aussi des programmes. Ainsi, l ensemble de ces travaux présentent plusieurs lacunes et faiblesses qui peuvent être résumées en ce qui suit: Une gestion centralisée du workflow: ces travaux considèrent une entité centrale pour le workflow qui a une vision globale de tout le processus et qui s occupe de la partie fonctionnelle et la partie sécurité du workflow. Approche statique: la politique de sécurité définie se base sur des règles de sécurité statiques qui se basent sur le modèle RBAC et qui prennent pas en considération toutes les contraintes qui peuvent être définies avec la spécification du workflow et l aspect dynamique du workflow. Ordre séquentiel des tâches: ces différents travaux ne considèrent que le mode séquentiel d exécution des tâches pour le workflow. Cette hypothèse est loin d être réelle vu que les tâches d un workflow peuvent être exécutées en parallèle ou aussi en concurrence. Le déploiement: ces travaux ne montrent pas comment la politique de sécurité pourra être déployée une fois qu elle est bien spécifiée. Workflow inter-organisationnel: ces travaux considèrent que le cas intraorganisationnel d un workflow alors qu en réalité on peut avoir des workflows où les tâches s exécutent dans des organisations différentes et indépendantes. On parle dans ce cas d un workflow inter-organisationnel. Contrôle de flux: les politiques de sécurité utilisées ne prennent pas en compte la gestion du contrôle de flux. Par ailleurs, même les convergences définies

174 160 Résumé pour le contrôle de flux et le contrôle d accès ne sont pas bien adéquates aux modèles utilisés. Par le présent travail, nous essayons de rémedier à ces différentes faiblesses par l application de l approche suivante: Nous choississons de baser notre politique de sécurité sur le modèle OrBAC pour rendre les règles de sécurité plus dynamiques et mieux adaptées au environnement des WFMS. Nous intégrons le contrôle de flux avec le modèle de contrôle d accès afin d avoir un modèle integré à utiliser pour le workflow. Nous proposons une procédure décentralisée pour l exécution sécurisée du workflow. Nous considérons les différentes contraintes qui peuvent être définies avec la spécification du workflow, spéciallement les contraintes temporelles. Nous considérons non seulement le cas intra-organisationnel mais aussi le cas inter-organisationnel d un workflow. Nous définissons une approche de déploiement de la politique de sécurité une fois qu elle est bien spécifiée. A.3 Un modèle intégré pour le contrôle d accés et le contôle de flux Pour s éloigner des faiblesses et des insuffisances des modèles de sécurité multiniveaux, nous avons choisi de nous baser sur les concepts du modèle DTE (Domain Type Enforcement) pour gérer le contrôle de flux. Ce modèle offre des concepts intéressants qui peuvent être utiles pour gérer le contrôle de flux au sein du workflow. Dans cette partie de la thèse, nous essayons de définir un modèle intégré qui nous permet d exprimer le contrôle d accès et de flux en utilisant le même format des règles. Ainsi, la politique de sécurité du workflow sera cohérente et elle pourra facilement être spécifiée. Pour cela, nous utilisons les concepts définis dans le modèle DTE. A.3.1 La notion de Entry Point Le modèle DTE utilise les deux matrices DDT (Domain Definition Table) et DIT (Domain Interaction Table) pour exprimer respectivement les droits qu un domaine

175 A.3 Un modèle intégré pour le contrôle d accés et le contôle de flux 161 a sur un type et les droits qu un domaine a sur un autre domaine. DTE ne s interesse non seulement à la définition des privilèges qu un domain peut avoir sur un autre mais aussi la façon par laquelle ce privilège est attribué. En effet, DTE contrôle le passage d un domaine vers un autre. Si un sujet veut passer d un domaine vers un autre il doit exécuter un programme ou une activité définie par le domaine destination. Chaque domaine définit un ensemble de Entry Points qui peuvent être utilisés par les sujets souhaitant transiter vers ce domaine. L exécution d un Entry Point implique deux règles: 1. Le sujet perd tous ses droits qu il possedait dans son domaine source. 2. Un nouveau ensemble de privilèges est associé au sujet dans son domaine destination. Cet ensemble depend de l Entry Point exécuté. A.3.2 Expression de la politique de sécurité Pour mieux formaliser le modèle DTE, nous définissons deux types de règles pour exprimer les deux matrices DDT et DIT: 1. SR DDT (type règle, domaine, type, privilège) 2. SR DIT (type règle, domaine 1, domaine 2, Entry Point) Nous rappelons qu une règle OrBAC est exprimée comme: SR(type, Organisation, rôle, activité, vue, contexte). Nous remarquons que la notion de rôle et d activité peuvent avoir respectivement la même signification que la notion de domaine et de type dans le système. De ce fait, nous déduisons que les règles SR DDT peuvent facilement être exprimées comme étant des règles OrBAC usuelles. Ces règles seront définies sous un contexte default. Donc les règles de contrôle d accès sont bien exprimées par le modèle OrBAC. Par contre, les règles SR DIT contrôlent des flux d information. Ainsi, pour être exprimées en utilisant des concepts définis dans OrBAC, nous fesons les correspondances suivantes: Le domaine source est considéré comme étant le rôle dans la règle OrBAC. Le domaine destination est considéré comme une vue dans la règle OrBAC. La transition entre les deux domaines peut être considérée comme étant une activité spécifique dans la règle OrBAC. Cette règle est appelée Enter. Le Entry Point peut être exprimé comme étant un contexte spécifique dans la règle OrBAC. Ce contexte sera noté through(e {i,j} ) pour spécifier que le passage entre le domaine D i et le domaine D j se fait à travers l exécution de l Entry Point E {i,j}

176 162 Résumé Ainsi une règle de sécurité qui exprime le contrôle de flux sera exprimée comme suit: SR (permission, org, D i, Enter, D j, through(e {i,j} ). Ces règles sont exprimées sous la même forme que les règles de contrôle d accès. Cette cohérence permet d avoir une politique de sécurité simple à spécifier et à gérer. Ces règles de sécurité représentent notre politique de sécurité qui va contrôler l exécution du workflow. A.4 Modélisation des WFMS et spécification de sa politique de sécurité A.4.1 Modélisation des workflows basée sur les RdP Pour être plus compréhensible et plus expressif, nous modélisons un workflow en utilisant un réseau de Petri. Ce type de modélisation a l avantage d être expressif et simple à comprendre. Pour que le modèle soit cohérent avec la politique de sécurité qu on va lui associer, nous basons la modélisation sur les mêmes concepts utilisés dans la spécification de la politique de sécurité. Ainsi, les notions de rôle, vue et activité utilisées dans OrBAC seront interprétées au niveau du réseau de Petri de la façon suivante: 1. R: un ensemble fini de rôles définis dans le process 2. V: un ensemble fini de vues utilisées durant l exécution du processus 3. A: un ensemble fini d activités associées avec les places du réseau de Petri Chaque place du réseau de Petri est définie au sein d une organisation et elle a un contexte d exécution associé à elle. Ce contexte sera noté cont(p i ). Pour le fonctionnement du RdP (Réseau de Petri), nous définissons un type particulier de jeton. Ce jeton est défini comme étant <r i, v i, cont(p i )>. Ce jeton spécifie quand il est placé dans la place P i, que l activité associée à la place P i doit être exécutée par le rôle r i et en utilisant la vue v i sous le contexte cont(pi). Le déclenchement de la transition T i qui suit directement la place P i implique les trois étapes suivantes: 1. Les opérations associées à la place P i ont été exécutées par le rôle r i, en utilisant la vue v i et sous le contexte cont(p i ) et en utilisant la permission nécessaire 2. Une fois le jeton est déplacé, l exécution s achève et r i n a plus accès à v i et aux opérations associées à P i 3. Quand le jeton est placé dans la place P i+1, toutes les opérations associées doivent être exécutées par le rôle r i+1 en utilisant la vue v i+1 et sous le contexte cont(p i+1 )

177 A.4 Modélisation des WFMS et spécification de sa politique de sécurité 163 A.4.2 Spécification de la politique de sécurité Après avoir modélisé le workflow, nous devons lui associer sa politique de sécurité qui sera responsable de contrôler l exécution du processus. Cette politique de sécurité assure ces trois fonctionalités: 1. Le contrôle d accès aux différentes ressources du système 2. Le contrôle des flux qui peuvent avoir lieu au sein du processus 3. Assurer le bon ordre d exécution des différentes tâches du processus Pour cela, nous associons les règles de contrôle d accès aux différentes places du réseau de Petri. Les règles de contrôle de flux, définies dans la section précédente, sont associées aux différentes transitions du réseau de Petri. Ainsi, une transition ne peut être déclenchée que lorsque la règle de contrôle de flux associée est valide et active. Ce fonctionnement est représenté dans la figure A.2. Figure A.2: Application du contrôle d accès et de flux sur le réseau de Petri Pour assurer l ordre d exécution des tâches du processus, nous définissons une politique de coordination qui prend en considération les différentes contraintes temporelles qui peuvent exister entre deux tâches. Ces contraintes sont résumées dans le tableau A.1 et la politique associée à ces contraintes est donnée dans le tableau A.2. Dans cette politique nous utilisons les prédicats déjà définis dans le modèle Nomad [CCBS05]: start(t) ( commencer T ), doing(t) ( exécuter T ) and done(t) ( finir T ), T est une tâche. Les deux prédicats start(t) et done(t) peuvent être utilisés comme étant des contextes spécifiques ou aussi des activités spécifiques. Concernant le contrôle de flux, il est exprimé par des règles tel que c était défini dans la section A.3. Ces règles définissent essentiellement le Entry point à exécuter

178 164 Résumé Symbole (T i, T j ) (T i, T j ) (T i, T j ) (T i, T j ) ±(T i, T j ) Contraintes temporelles T i doit commencer juste après T j T i doit commencer avec T j T i doit commencer après le commencement de T j T i doit finir avec T j T i doit finir avant T j Table A.1: Les différentes contraintes temporelles entre deux tâches temporal Associated Policy constraints - P(start(T j ), default) (T i, T j ) - O(start(T i ), done(t j )) - P(start(T i ), default) (T i, T j ) - P(start(T j ), default) - O(start(T i ), start(t j )) - O(start(T j ), start(t i )) - P(start(T i ), default) (T i, T j ) - P(start(T j ), default) - O(done(T i ), done(t j )) - O(done(T j ), done(t i )) - P(start(T j ), default) (T i, T j ) - O(start(T i ), doing(t j )) - P(start(T j ), default) ±(T i, T j ) - O(done(T i ), doing(t j )) Table A.2: Politique de coordination

179 A.4 Modélisation des WFMS et spécification de sa politique de sécurité 165 pour changer de rôle. Comme c est dit en dessus, ces entry points contrôlent le déclenchement des différentes transitions du réseau de Petri modélisant le workflow. A.4.3 Environnement sécurisé pour l exécution distribuée du workflow Dans cette partie du travail, nous avons défini une procédure d exécution du workflow. Cette procédure exécute le workflow dans un environnement distribué et sécurisé. En effet, les différents agents du workflow contribuent à assurer la sécurité du workflow. Donc, nous considérons qu il n y a pas une seule entité centrale qui a une vision globale sur le workflow et qui gère tout, par contre chacun des agents du workflow participe non seulement à l exécution du workflow mais aussi à maintenir la cohérence de la politique de sécurité. L exécution de chaque tâche doit respecter la politique de sécurité déjà définie et aussi doit respecter l évolution de l exécution du workflow. La procédure que nous avons définie prend comme input le modèle en réseaux de Petri du workflow et la politique globale associée à la spécification du workflow. Le déroulement de la politique génère une politique locale applicable au niveau de chaque tâche du réseau de Petri. Cette politique locale contient les différents contextes d exécution des différentes places. Ces contextes d exécution sont générés par rapport à l exécution des tâches antérieures. La procédure considère la politique de contrôle d accès, de contrôle de flux et aussi la politique de coordination. A.4.4 Complexité du problème de satisfiabilité du workflow Dans cette partie, nous avons étudié la complexité du problème de satisfiabilité d un workflow. Ce problème se définit comme étant est ce qu il y a une affectation possible des différents utilisateurs aux différents rôles qui satisfait le workflow et sans violation d aucune contrainte?. Pour cela, nous divisons ce problèmes en trois sous problèmes et nous étudions la complexité de chacun: 1. Etant donné un ensemble de contraintes, cette base est elle consistante? complexité polynomiale de n 3 avec n le nombre de contraintes. 2. Etant donnée une base de contraintes qui soit consistante, peut-t-on trouver une affectation valide des utilisateurs aux différentes tâches et qui satisfait la base des contraintes? le problème est NP-complet 3. Etant donnés une affectation possible et un ensemble cohérent de contraintes, l affectation respecte-t-elle l ensemble de toutes les contraintes? Complexité polynomiale d ordre n*m avec m le nombre de tâches et n le nombre de contraintes.

180 166 Résumé A.5 Déploiement de la politique de sécurité A.5.1 Différents modes d exécution et types des workflows L exécution d un workflow peut être soit centralisée soit distribuée. Dans le premier cas, le workflow entier est sous le contrôle d une seule entité centrale. Cette entité centrale s occupe de gérer l exécution du workflow. C est elle qui initie le workflow et elle synchronise l exécution des différentes tâches et communique directement avec les agents du workflow pour envoyer les tâches à exécuter ou alors recevoir le résultat d exécution. Dans le cas distribué, cette entité n est plus responsable que de l initiation du workflow. Ensuite, l exécution du workflow est suivie par l ensemble des agents du workflow. Chaque agent exécute la tâche qui lui est associée et puis il envoit le reste du workflow à l agent qui le succède. Dans ce cas là, tous les agents du workflow ont une connaissance des différentes dépendances qui existent entre eux. Ils connaissent aussi l ensemble des conditions qui relient les différentes tâches du workflow. D un autre côté, les différentes tâches d un workflow peuvent appartenir ou pas à la même organisation. Si les tâches du workflow sont exécutées au sein de la même organisation, on parle d un workflow intra-organisationnel, sinon, on parle d un workflow inter-organisationnel. Le deuxième cas est beaucoup plus complexe. En effet, en plus du contrôle qui doit être maintenu au sein des différentes organisations, on doit aussi gérer l ensemble des communications et interactions qui peuvent avoir lieu entre les différentes organisations. Ainsi, il faut assurer non seulement le contrôle d accès mais aussi il faut s occuper du contrôle de flux intra et interorganisationnel. A.5.2 Approches de gestion de politiques de sécurité Pour gérer la politique de sécurité d un workflow, deux approches sont possibles: l approche outsourcing et l approche provisioning. Ces deux approches sont representées respectivement par les deux schémas donnés dans les figures A.3 et A.4 pour un workflow centralisé et distribué. Dans l approche outourcing, l entité centrale du workflow s occupe de la sécurité du workflow. Ainsi, pour exécuter une tâche, chaque agent du workflow doit demander l autorisation à cette entité centrale qui communique avec le serveur de politique. Par contre, dans le cas d une approche provisioning, cette entité centrale délège la tâche de sécurité du workflow aux differents agents du workflow. Ainsi, pour exécuter une tâche, les agents doivent directement demander l autorisation au serveur de la politique.

181 A.5 Déploiement de la politique de sécurité 167 A.5.3 Déploiement de la politique de sécurité Pour définir l approche de déploiement de la politique de sécurité, nous distinguons le cas intra-organisationnel et le cas inter-organisationnel du workflow. Le déploiement de la politique dépend du type du workflow et aussi de l approche de sécurité utilisée. A Le cas intra-organisationnel Pour le cas intra-organisationnel, le schéma général de déploiement est donné dans la figure A.5. Le schéma est divisé principalement en trois parties. La première partie constitue la spécification et la validation du workflow. Les informations au niveau de l outil de modélisation sont ensuite transférées vers le serveur de la politique. Ce serveur de politique, qui represente la deuxième partie, utilise ces éléments du workflow pour générer sa politique de sécurité abstraite. Cette politique est enregistrée dans une base afin d être utilisée pour générer la politique concrête. La génération de la politique de sécurité se fait en utilisant l API OrBAC. La troisième partie représente l environnement d instantiation du workflow. Au cours de cette phase, le workflow est exécuté. Au niveau de cette partie nous remarquons l existence de deux entités essensielles qui vont gérer la communication entre l entité coordinatrice du workflow et le serveur de la politique. Il s agit du PEP (Policy enforcement Point) et du PDP (Policy Decision Point). Le PEP communique avec le PDP pour lui demander la politique de sécurité à utiliser lors de l exécution du workflow. Le PDP génère la politique de sécurité concrête associée au workflow en utilisant la politique de sécurité abstraite initiallement générée. L exécution du workflow doit respecter la politique de sécurité fournie par le PDP. Cette politique est maintenue lors de l exécution par l entité coordinatrice du workflow vu qu on utilise une approche provisioning. Figure A.3: L approche outsourcing dans un workflow centralisé et distribué