enforcing access control in workflow systems with a task engineering approach

Int. J. Internet Technology and Secured Transactions, Vol. 4, No. 1, 2012 55

Copyright © 2012 Inderscience Enterprises Ltd.

Enforcing access control in workflow systems with a task engineering approach

Hamid Hatim*, Hanan El Bakkali and Ilham Berrada Université Mohammed V-Souissi, ENSIAS, BP: 713, Agdal – Rabat, Morocco Fax: 00212-5-37-77-72-30 E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] *Corresponding author

Abstract: The need for ‘role engineering’ becomes evident once a decision has been made to adopt role-based access control (RBAC) to ensure access control in a computer system. Role engineering is a process to define roles, permissions, and role hierarchies. Therefore, it is a critical step in deploying any RBAC-oriented system. The question is even more crucial for workflow management systems: additionally to role engineering, a ‘task engineering’ process could be needed to allow the satisfaction of access control constraints even in critical situations. In this paper, we propose an approach of task engineering to improve access control enforcement in workflow management systems. By task engineering, we mean the process to examine the granularity of each workflow’s task in a way to meet – at run time – the main access control requirements, precisely the least privilege and separation of duties principles. This approach uses the constraints satisfaction problem (CSP) formulation and resolution method.

Keywords: workflow; access control; role-based access control; RBAC; role engineering; task engineering; granulatrity; atomicity; constraints satisfaction problem; CSP.

Reference to this paper should be made as follows: Hatim, H., El Bakkali, H. and Berrada, I. (2012) ‘Enforcing access control in workflow systems with a task engineering approach’, Int. J. Internet Technology and Secured Transactions, Vol. 4, No. 1, pp.55–70.

Biographical notes: Hamid Hatim is Researcher and PhD student in the field of Computer Sciences and Information Technology at ‘Ecole Nationale Supérieure d’Informatique et d’Analyse des Systèmes (ENSIAS)’, Mohammed V-Souissi University, Rabat, Morocco. He obtained his Master in Computer Science from the same institute. His research interests include access control models in workflow management systems.

Hanan El Bakkali is Associate Professor and Head of Information Systems Security Option at ENSIAS. She is a member of both Information Security Research Team (ISERT) and AL Business Intelligence on Network Information (BIRONI) research teams. Her current research focuses on electronic transactions security, trust models and access control models in workflow management systems.

56 H. Hatim et al.

Ilham Berrada is a Full Professor at ENSIAS and Head of AL BIRONI research team. She occupies currently, in the interim, ENSIAS’s Director post. She is interested in data, text and web mining and she is involved in several research projects about CRM improvement, multi-criteria decision and fraud detection.

1 Introduction

Role-based access control (RBAC) has become the norm in many of today’s organisations when they are enforcing access control to users of their systems. By granting permissions to roles played by users rather than to users themselves, it has greatly facilitated the access control administration in companies that have thousands of employees since users with similar functions can be grouped under the same role. Yet, the problem that arises is the fact that is there often a thought that a system can be secured by simply acquiring and installing a product, as well as you can make an extension to your application through a plugging module. Nevertheless, RBAC is not such a product, because access control consists in designing a model by specifying a policy and mechanisms to apply this policy. So, to employ RBAC it is first necessary to identify a set of roles for the organisation since, the needs of each enterprise are different and require specific tailoring of access control requirements based on local analysis. These roles must accurately reflect the activities, functions, and responsibilities within the organisation (Cone and Davis, 2008).

Role engineering is a process that involves several steps: the first one is the process of finding the good and the smallest set of roles. This process has been recognised as one of the most important and challenging tasks when implementing RBAC (Vaidya et al., 2007) and several works restrict the role engineering at this stage (Colantonio et al., 2008; Ene et al, 2009). The next step is to organise these roles into a hierarchical relationship in which senior roles in the enterprise inherit the permissions of their junior roles. In this paper, we also consider a third step to establish a delegation relationship between these roles when the corresponding user is unavailable or too overloaded with work to successfully complete a task in a given workflow.

Whatever security policies are expressed in terms of roles when RBAC is adopted as access control model, in a workflow management system, the task carried out by a role is a central concept. To point out the task’s central position in workflow systems, a task-oriented access control (TBAC) model was developed as a different paradigm to tackle the authorisation issue in distributed computing and information processing activities with multiple points of access, control, and decision making such as that found in workflow management systems (Thomas and Sandhu, 1997). This work has been followed by several researches that place task in the heart of their attention (Liao et al., 2005; Wang and Zhang, 2007; Wolter et al., 2008). One of the most recent expresses authorisations within the workflow model, enabling the support of resource allocation pattern, such as separation of duty, role-based allocation, case handling, and history-based allocation in business process modelling notation (BPMN) (Wolter and Schaad, 2007). Unfortunately, no one exploits – at run time – the task granularity in order to satisfy the access control constraints.

For this reason, we propose in this paper a task engineering approach that considers the issue of the task granularity. By task engineering, we mean the process of

Enforcing access control in workflow systems 57

decomposing some tasks of a given workflow in order to satisfy – at run time – the main access control requirements in workflow systems. Task engineering is thus complementary to role engineering regarding to enforcement of the access control in workflow systems.

Our approach uses the constraints satisfaction problem (CSP) formalism to model a task-user assignment at run time while satisfying the access control constraints.

We will first present in Section 2 the RBAC model and why it is suitable in the context of workflow management systems. In Section 3, we describe the main workflow access control constraints. In Section 4, we outline both the importance and the limitations of the role engineering process in the enforcement of the access control in workflow systems. Our contribution is presented in Section 5. Finally, we summarise the discussions and conclude in Section 6.

2 RBAC in brief

RBAC is the ANSI/INCITS standard regarding the access control models in computer systems (ANSI INCITS 359, 2004). In a RBAC environment, first, a system administrator defines a set of roles and for each role, he associates a set of access privileges (permissions) to specific computer resources. Each user will access to the system only based on the role he plays.

RBAC consists of four main entities: users, roles, permissions and sessions. A session is a concept that is bound to a single user and allows the user to activate the permissions of a subset of roles to which he/she belongs.

Adopting RBAC as an access control model offers several advantages such as:

• The security administration is so easy since the number of roles in an organisation is usually much smaller than the number of users in that organisation (Ferraiolo et al., 2007).

• Users are assigned to the roles and they automatically receive all the permissions associated with the assigned roles. After that, the security configuration is relatively stable since roles and permissions typically change much more slowly over time than do personnel.

• Once the migration to RBAC is done, just an administrative (rather than a technical) staff can perform the assignment of users to roles.

Besides these advantages, RBAC has proven a certain efficiency to meet workflow access control requirements. In the next section we focus mainly on two of these requirements: separation of duty (SoD) and least privileges (LP) principles.

3 Main workflow access control requirements

As a computerised systems used for supporting business processes in various application domains like finance, banking, health care, telecommunications, and manufacturing, workflows have a number of access control requirements. Among the most critical of these requirements are SoD and LP principles.

58 H. Hatim et al.

Some works as Bertino and Ferrari (1999), Botha and Eloff (2001), Chen and Crampton (2007b), and Buyens et al. (2009) have extended RBAC to satisfy adequately at least these two principles during a workflow execution (i.e., at run time) where new situations of conflict of interest may appear between users, roles, permissions, and tasks.

3.1 SoD principle

SoD could be defined as a security principle used to formulate multi-person control policies, requiring that two or more different users be responsible for the completion of a sensitive task or a set of related tasks (e.g., a workflow).

So, it prevents a single user to hold enough power or privileges to commit a fraudulent act. For example, a user must not be allowed to make an order and then validate the same order.

In the workflow access control literature, there is always a distinction between two kinds of SoD: static SoD (SSoD) and dynamic SoD (DSoD). SSoD and DSod differ with regard to the time at which the SoD constraints are applied.

SSoD is established at the workflow’s administration time and not during its execution. In RBAC-based models, there are, essentially, two mechanisms to implement SSoD policies: the well known SMER (statistical mutual exclusion of roles) and the definition of conflicting entities referenced in Botha and Eloff (2001) as the conflicting entities administration paradigm (CoAP).

Two roles can be regarded as mutually exclusive (or conflicting) if one person is never allowed to be a member of both roles simultaneously. This is the case if their combined access permissions would allow the completion of an entire business process (Perelson and Botha, 2000).

Conflicting users could be defined as persons who may stand to gain by conspiring. In practise such users may be family members or friends.

In Botha and Eloff (2001), we find the concept of conflicting tasks that are defined as tasks that require some conflicting permissions to complete and they must be executed by different users. However, conflicting tasks may also be defined without enforcing the identification of conflicting permissions.

SSoD in workflow systems could also be enforced by focusing on sensitive tasks. For example, when a sensitive workflow is composed of n tasks, a SSoD constraint could require the cooperation of at least k (for some k ≤ n) different users to complete the workflow.

On the opposite of SSoD, within DSoD constraints a user or conflicting users may be assigned to conflicting roles, but restrictions are imposed while a user is actively logged onto the system. As described in Papenfus and Botha (2000), in the context of WFMS, dynamic constraints start with the execution of a workflow instance based on the concept of role activation and also on the history of user accesses.

When considering other conflicting entities than roles, we would have additional DSoD constraints such as:

• dynamically conflicting permissions may not be exercised by the same user or dynamically conflicting users in the same workflow instance

• dynamically conflicting tasks may not be performed by the same user or dynamically conflicting users in the same workflow instance.


Enforcing SoD policies in WFMS is based on both SSoD and DSoD. With regard to role-user assignment, role-permissions association and user-task affectation, DSoD provide the enterprise with greater operational flexibility than SSoD but also with additional complexity.

3.2 LP principle

LP principle is one of the most challenging issues in security systems. It aims to ensure that each user has no more than the needed permissions to perform the task he is aiming to perform.

Indeed, the purpose of LP is to activate for a user the smallest set of permissions (or privileges) that are necessary to accomplish a task (Bertino and Ferrari, 1999). Moreover, these permissions must be removed once the work is performed.

LP has to be respected at each beginning or end of a user action (initiation of a workflow, task execution, role activation, etc.). For example, LP prevents a user to activate a role if the execution of the current task does not need necessary the permissions assigned to this role.

Unfortunately, when business requirements dominate over security constraints (which is frequent) LP is often the first neglected.

In the next section, we will show how role engineering tools are both crucial and insufficient to enforce access control in WFMS.

4 The role engineering process

In several works (Vaidya et al., 2007; Zhang et al., 2008; Ene et al., 2009), role engineering is defined as the problem of discovering an optimal set of roles from existing user permissions. This process is established during the administration time, i.e., once role definitions are established, there is no more flexibility to shift responsibilities or to demand additional permissions during the execution (Schlegelmilch and Steffens, 2005). Often, role engineering takes place in three steps: determining the role set, establishing a hierarchy between them and allowing the notion of delegation. To summarise, role engineering is the process of defining roles and related issues, such as permissions, role hierarchies, and role delegation as they pertain to the user’s functional use of systems, applications, business processes and their associated WFMS. Therefore, it is a critical step in deploying any RBAC-oriented WFMS.

In the following, the main steps of role engineering will be presented and their impact in the enforcement of access control constraints.

4.1 Establishing the set of all roles in a company

A role is a set of connected behaviours, rights and obligations as conceptualised by actors in a social situation. It is a job function within the context of an organisation with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role (ANSI INCITS 359, 2004). A role can be represented by a pair (r_name, r_p), where r_name is the name of r, and r_p represents the set of privileges of r.

60 H. Hatim et al.

There are two basic approaches towards the establishment of the set of role: top-down and bottom-up (Ferraiolo et al., 2007; Vaidya et al., 2007; Zhang et al., 2008; Colantonio et al., 2008; Cone and Davis, 2008; Ene et al., 2009).

4.1.1 The bottom-up approach

The bottom-up approach considers the access control models that companies already have in place before migrating to RBAC. This approach start by carefully analysing the business processes in order to break them down into more elementary components and identify which system futures are necessary to carry out specific tasks (Colantonio et al., 2008). Bottom-up approach uses the well known clustering techniques from the data mining that consists in a division of data into groups of similar objects. Indeed, from a data mining point of view, a role is a categorical (nominal) variable, for example ‘senior’, ‘employee’, ‘secretary’. So in theory, the obvious way to discover the set of roles is the clustering.

Figure 1 Example of roles available in a company (see online version for colours)

4.1.2 The top-down approach

Known as an interview process, the top-down approach starts with a business process definition or scenario, extracts candidate roles from these descriptions, and then transforms them into an enterprise role concept (Colantonio, Di Pietro and Ocello). This approach reminds the renowned method of ‘use case’ in UML. Note that this approach is a manual process and requires a high level analysis of the business process by specialists.

In practise, the combination of these two approaches is needed to obtain the correct set (the optimised set) of roles. When the bottom-up approach serves to have all candidate roles in the enterprise, the top-down approach serves to optimise the set of established roles. As shown in Figure 2, according to the business need of the organisation, an expert staff can decide to merge some roles or creating missed roles.


Figure 2 Optimisation of the role set by a top-down approach (see online version for colours)

4.2 Building the hierarchical role graph for the selected roles

The role set can be more optimised if a hierarchy relation is maintained between the roles. The notion of role hierarchy allows senior roles to inherit the permissions of the corresponding junior roles.

We have noted that the main limitation of using only bottom-up approach to establish the roles is that inheritance between roles is impossible. Suppose that r1 and r2 are two roles defined by the bottom-up approach using k-means algorithm. Thus, r1 and r2 are not overlapping (k-means partitions the dataset into k non-overlapping clusters). Consequently, the intersection of their permissions sets is empty:

( ) ( )1 2r r .perm perm = ∅ (1)

Once again, this explains the need to combine the two approaches of role engineering. In the absence of role hierarchies, it is inefficient and administratively cumbersome to

specify general permissions repeatedly for a large number of roles, or to assign a large number of users to general roles (Perelson and Botha, 2000). The ANSI standard on RBAC (ANSI INCITS 359, 2004) describes a hierarchy between two roles as a partially ordered relation defining a seniority relation between roles ‘≥’, whereby senior roles acquire the permissions of their juniors and junior roles acquire users of their seniors. Formally, if r1 ≥ r2 (r1 is senior role of r2) then perms(r2) ⊆ perms(r1) and users(r1) ⊆ users(r2).

For example, the role DOCTOR is a junior role to the role SURGEON, then SURGEON inherits all the permissions of DOCTOR. Finally, Role hierarchy reveals interesting also when removal of redundancy among the role set (Sun et al., 2006).

4.3 Handling the delegation relation between the roles in the hierarchical graph of roles

Once having established the set of all roles with a hierarchical relationship, we must define a delegation relationship between these roles. In a hospital, for example, if a doctor is absent, one of his colleagues should play his role on his behaviour. This is done through a delegation process defined during the administration time that will be effective according to the context during the run time of the workflow execution (Wainer et al.,

62 H. Hatim et al.

2007; Wei and Shu, 2007). This process is concerned by role engineering because not all roles are candidate of delegation and a carefully analysis is necessary to determine the delegation relationship. For example, the ‘patient’ role cannot be delegate while in a web shop system, both roles of ‘customer’ and ‘seller’ can be delegated. In this case, role engineering must determine the different conditions under which the delegation can be set in a correct manner.

4.4 Role engineering and workflow access control

Effective role engineering tools and methods may aid in the application of SoD and LP principles in different applications and WFMS of large scale organisations. For example, the SoD could be enforced by defining exclusive roles (conflicting roles) and LP could be implemented by assigning each role a minimum set of permissions required to perform each task.

Among the main challenges in role engineering is the establishment of a role hierarchy while taking into account SoD and LP constraints. Indeed, when dealing with the enforcement at administration time of SoD in workflow systems on the basis of RBAC models, it arises the important question of the interaction between SSoD constraints and role inheritance via the role hierarchy. The main goal is to prevent that roles inheritance conduct to a violation of SOD constraints as SMER.

Some works as Chen and Crampton (2007a) and Colantonio et al. (2008) propose an extension to RBAC model that contains a more flexible approach to permissions and permission inheritance that makes it possible to define SoD constraints on two roles that have a common senior role and for a user to be assigned to or activate the senior role. Such extended models require, however, additional role engineering work. Moreover, LP constraints must be applied – at run time – to prevent such privileges inheritance through role inheritance that could give a user more privileges than he needs to carry out his current task within a workflow instance.

Similarly, particular care must be taken when enforcing LP with regard to WFMS where role delegation is permitted. In several role delegation scenarios, it is not easy to anticipate in advance (and then at administration time) all the required permissions by the delegate role for completing some future needed tasks. Delegating less permissions than required for carrying out these tasks may forbid task execution while delegating more permissions than required would violate LP principle.

Unfortunately, when business requirements dominate over security constraints (which is frequent) LP and SoD are often the first sacrificed. In the next section, we will show how our proposed approach contribute in enforcing DSoD and LP constraints at run time in situations where role engineering tools are no more useful.

5 The proposed ‘task engineering’ approach for workflow access control

An automated business process or workflow could be seen as a set of ordered tasks that must be carried out by users. Because of cooperative work, some tasks are complex and require the intervention of several users with different roles: In a hospital for example, a surgery involves at the same time a surgeon, an anesthetist and a resuscitator.

Nearly all large enterprises use workflow systems to manage particularly complex business processes. Tasks in a given workflow could be coarse-grained (more complex),


fine-grained (less complex) or atomic (indivisible). Therefore, the number of users that can collaborate in the execution of a task depends on its granularity.

A workflow management system, at each workflow execution tries to assign each task to a single user depending on his roles and availabilities. This assignation must respect the access control policy of the enterprise and particularly the SoD and LP constraints.

In what follows, we present our task engineering approach that takes place at the run-time in order to satisfy access control constraints.

5.1 Research rationale

In our approach, we introduce the task engineering as a process to act on the granularity of each task in a way to meet the main access control requirements in workflow systems as LP and SoD.

Granularity is the extent to which a task is broken down into small parts. Few works such as Bertino and Ferrari (1999) and Wolter et al. (2008), consider the task granularity as a main issue. In our approach, we consider two kinds of tasks: atomic and non-atomic task.

From an access control point of view, choosing the right task granularity at administration time is not easy. So, in this paper, our task engineering process could obtain at run-time the suitable granularity of a task within a workflow instance on the basis of its decomposition into atomic sub-tasks in order to meet both business and access control constraints.

In fact, a workflow instance execution might be stopped if there is no appropriate user to assign to the current task instance with regard to dynamic access control or availability constraints.

Let consider the simple workflow of Figure 3 that is composed of three sequential tasks corresponding to a business process in some enterprise. It is possible that such problematic scenario occurs: U1 has performed Task 1, and now Task 2 must be executed, but all users authorised to perform Task 2 within this workflow are unavailable or in conflict with U1 regarding SoD or LP constraints.

Figure 3 A problematic workflow execution

In such a case, the proposed task engineering could be useful to increase the flexibility of the workflow system by dividing this task (Task 2) into two or more sub-tasks that require less permissions and could be executed by more than one user without creating a situation of conflict.

Figure 4 A possible solution

64 H. Hatim et al.

Thus, it would be possible to enhance the satisfaction of both DSoD [because a complex task is decomposed into several smaller steps, which are executed by different individuals (Bertino and Ferrari, 1999)] and LP constraints (since the sub-tasks require less permissions than the original task) and allow the ending of the workflow instance execution.

5.2 Assumptions and prerequisites

We assume that all work about role engineering is already done at administration time: proper role set and role hierarchy and delegation are established with correct role-user assignment and role-permission assignment, with regard to access control constraints.

We also assume that the workflow system is able to identify conflicting entities (users, roles, tasks …) at both administration and run times. In El Bakkali and Hatim (2009), there is an example of rule under which an access control decision might be taken about the task instance execution with regard to the conflicting entities.

An important prerequisite for (and also a part of) our task engineering approach is a preparation step that consist of formulating all tasks of the workflow on the basis of their atomic sub-tasks. This preparation step should be done (perhaps automatically) at the administration time for all the tasks of the workflow.

Finally, we suppose that each workflow within the workflow system has a task-role and task-permissions assignments that respect – at administration time – both the business and access control constraints (mainly, SoD and LP).

5.3 Definitions

Lot of definitions of workflow, workflow instance and workflow management system exist in the literature (Perelson and Botha, 2000; Lul and Jiang, 2006; El Bakkali and Hatim, 2009). For the purpose of this paper, we only adopt the simpler workflow definition in which a workflow is a set of tasks.

• Def 1: An atomic task represents a task that cannot be further divided into small sub-tasks.

• Def 2 (Ye et al., 2006): An atomic task is a set of operations that respect the two conditions bellow:

a until the entire set of operations completes, no other process can know about the changes being made (invisibility)

b if any of the operations fail then the entire set of operations fails, and the state of the system is restored to the state it was in before any of the operations began.

We can remark that Def 2 is more precise than Def 1 and could be used in our approach. Nevertheless, we prefer in this paper to use the following definition:

• Def 3: An atomic task is a task that is associated with an atomic permission or could not be associated to more than one user. For example, it is a task that involves a single operation on a single object.

• Def 4: Task representation.


A task t is represented by a quadruplet (RT, PT, Id-T, AT) where:

RT the set of all roles that can perform the task T

PT the set of all permissions that are necessary to perform T

Id-T the identification of T in the workflow

AT the set of all acceptable permutations ATk of the n atomic sub-tasks Tai of T, where each atomic sub-task could be represented as: Tai = (Rt, pai, Id-T, (Tai)).

The execution of T (more precisely, an instance of T within a workflow instance, but in the following, we will confuse – for convenience – a task with its instance) could be done with different manners depending of the execution order of the Tai. In fact, it is possible that two atomic sub-tasks Ta1 and Ta2 of T could be executed – in the context of T’s execution – in two different ways: Ta1 → Ta2 and Ta2 → Ta1, without changing the semantic and the result of the execution of T (as in Figure 5).

Figure 5 Different atomic sub-tasks permutations

Each ATk is a permutation (Tak1,…,Takn) of the set {Ta1,…,Tan} of the sub-tasks of T. Let m be the cardinal of AT. Generally, m not exceeds four or five permutations and it is very inferior to n! (the number of all possible permutations).

5.4 Applying the ‘task engineering’ process

As we have shown before, a workflow instance execution might be stopped if there is a lack of users that could perform the current task instance with regard to dynamic access control or availability constraints.

To bypass such a critical situation, we proceed by splitting this task into two sub-tasks, and if the critical situation is not resolved yet, we divide it into three sub-tasks, and so on, until the situation is ‘unblocked’ or all the sub-tasks are atomics.

To apply this method we assume that all tasks of the workflow are formulated on the basis of their atomic sub-tasks as it is mentioned before (cf. Section 5.2).

Due to this preparation step, the first step provides a formulation of the problem of assigning users to the current task as a CSP as explained in the sub-section below.

Finally, we resolve the CSP with a suitable algorithm. The problem is resolved if all the atomic sub-tasks are assigned to users without violating any constraint.

In this paper two versions of a non-deterministic algorithm are presented. The second version extends the first by taking into account the different permutations of the atomic sub-tasks of a task T that reflect the different orders of execution of the sub-tasks that correspond correctly to the execution of T.

66 H. Hatim et al.

5.4.1 CSP formulation

We express the task-user assignment (of current task t) as a CSP represented by the triplet (V, D, C) where:

• V is the finite set of variables. Our variables are the atomic sub-tasks of T. So V = {Ta1,…,Tai,…,Tan} where Tai is an atomic sub-task of T.

• D is the domain of all possible values that could be tacked by each variable. A possible value of an atomic task Ta is a user that his role(s) is (are) included in the roles associated to Ta. Thus, D is included in U (the set of all users).

• C is the finite set of constraints. Constraints arise from dynamic workflow access control constraints as LP or DSoD and also from business constraints (e.g., availability of the users).

In this paper, we do not express the constraints on tasks, users and roles formally. This will be the purpose of a future work. We will probably use for this purpose predicates on tasks, users, roles, permissions, workflows and context.

In Wolter et al. (2008) for example, each task-based constraint c ∈ C defines a task allocation restriction on one or two tasks. A constraint specifies additional conditions that must hold beyond the user’s role at runtime.

5.4.2 Resolving the CSP at run time

The CSP resolution for a task T occurs when the attempt to execute T produce a critical situation as explained before. In other words, assigning the same user to all atomic sub-tasks of T is impossible.

To resolve our CSP, we propose two versions of a variant of the classical depth-first algorithm with backtracking that operate as follows:

Version 1: Initially T02 = T = (Ta1,…,Tai,…,Tan) and i = 1; While i < n do If i is even and T(i – (i div 2))1 contains more than one atomic task then: a.1 We divide (by a dichotomy operator) T(i – (i div 2))1 into two distinct and

complementary parts Ti1 and Ti2 (with the same number of atomic tasks or Ti1 will have one additional task)

a.2 We assign (more precisely, we choose to assign) two new different users Ui1 and Ui2 from D respectively to all the atomic sub-tasks of the two sub-tasks Ti1 and Ti2;

If i is odd and T(i – (i + 1 div 2))2 contains more than one atomic task then: b.1 We divide (by a dichotomy operator) T(i – (i + 1 div 2))2 into two parts Ti1 and Ti2

(with the same number of atomic tasks or Ti1 will have one additional task); b.2 We assign (more precisely, we choose to assign) two new different users Ui1 and Ui2

from D respectively to all the atomic sub-tasks of the two sub-tasks Ti1 and Ti2; If this assignation satisfies all the constraints of C, then we stop the execution of the algorithm (exit) because the CSP is resolved; If there are a new couple of users in D to assign (the CSP is not yet resolved) If i is even then we go to the step ‘a.2’, Else, we go to step ‘b.2’ Else (there are no more couples of users to try) i ← i + 1 (we will begin another iteration if i < n elsewhere the algorithm is stopped without finding a solution).


This non-deterministic algorithm tries to assign the minimum number of users to the initial task T while satisfying the constraints of C. For example, in the beginning, it tries to assign only two users to the task T.

The complexity of this algorithm is in the order of O(p * (p – 1) * n), where

n the number of atomic tasks in T

p cardinality of D.

The Version 2 of the algorithm considers the set AT of the permutations of the atomic sub-tasks (Ta1,…,Tai,…,Tan) that reflect an order of execution of the sub-tasks that correspond correctly to the execution of T. Indeed, it is possible that one permutation require fewer users (with regard to access control constraints) than another.

Version 2:

Initially: State ← ‘fail’, nu ← card(D) and k ← 1

While k < m (m = card(AT)) do

T02← ATk = (Tak1,…,Taki,…,Takn)

i ← 1;

While i < n and i < nu do

a. If i is even and T(i – (i div 2))1 contains more than one atomic task then:

a.1. We divide (by a dichotomy operator) T(i – (i div 2))1 into two distinct and complementary sub-tasks Ti1 and Ti2;

a.2. We assign (more precisely, we choose to assign) two new different users Ui1 and Ui2 from D to respectively all the atomic sub-tasks of the two sub-tasks Ti1 and Ti2 and different users of the other sub-tasks (T(i – (i div 2))2, Tj1 and Tj2 for j = i – (i div 2) + 1 to i – 1);

b. If i is odd and T(i – (i + 1 div 2))2 contains more than one atomic task then:

b.1. We divide (by a dichotomy operator) T(i – (i + 1 div 2))2 into two tasks Ti1 and Ti2;

b.2. We assign (more precisely, we choose to assign) two new different users Ui1 and Ui2 from D to respectively all the atomic sub-tasks of the two sub-tasks Ti1 and Ti2 and different users of the other sub-tasks (Tj1 and Tj2 for j = i – (i div 2 + 1) to i – 1);

c. If this assignation satisfies all the constraints of C, then nu ← min(nu, i + 1), state ← success and we go to step ‘f’ (because the CSP is resolved for this ATk);

d. If there are a new couple of users in D to assign (at this step the CSP is not yet resolved) then (backtracking):

If i is even then we go to the step ‘a.2’

Else, we go to step ‘b.2’

e. Else (there are no more couples of users to try) i ← i + 1 (we will begin another iteration if i < n and i < nu)

k ← k + 1 (at this stage the algorithm tries another permutation to find another solution).

If state = success then we have resolved the CSP with the minimum number nu of users.

Else we have failed to resolve the CSP.

68 H. Hatim et al.

The complexity of this algorithm (without a specific strategy) is in the order of O(m * min(p, n) * (p! / (p – (min(p, n) + 1)!), where

n the number of atomic tasks in T

m the number of acceptable permutations of T

p cardinality of D.

In order to implement this algorithm we have to define a strategy for the choice of the couple of users to assign to the two new sub-tasks. Finding the optimal strategy to apply will be the subject of another work.

6 Conclusions

Migrate the access control model of an enterprise to RBAC is a hard transformation process. A successful implementation of RBAC depends on the role engineering that identifies – at the administration time – the correct set of roles and the correct assignment relations between all entities involving with these roles. Additionally to role engineering, workflow systems require a further work at – run time – that we call ‘task engineering’ for a successful implementation of RBAC as an access control model. In this way, we have presented an approach that is based on a CSP formulation to find the right granularity of a complex task in order to assign each sub-task to a suitable user without any conflict.

Many others supports of security constraints could be derived from such task engineering approach beyond the case of conflicting situations:

• roles can be activated and de-activated based on the progress of the task execution (an atomic sub-task by an atomic sub-task)

• dynamic activation and deactivation of permissions associated to a role on the basis of the progress of the task execution.

7 Future works

Future works will focus on enhancing our approach, on one hand, by completing it with the modelling of the main workflow access constraints and on the other hand, by testing other search methods as well as different optimisation techniques particularly with regard to the choice of the users to assign at each step.

In order to realise our approach, we need to provide some suitable method to assign a set of atomic sub-tasks and related permutations to any task within a workflow. Proposing such a method is object of future work and will be part of our approach.

Finally, our approach is ‘local’ to the current task, we are motivated to extend it in order to take into account constraints on the following tasks in the workflow instance (as with forward checking).


References ANSI INCITS 359 (2004) ‘American national standard for information technology – role based

access control’, ANSI INCITS 359-2004, February 2004. Bertino, E. and Ferrari, E. (1999) ‘The specification and enforcement of authorization constraints in

workflow management systems’, ACM Transactions on Information and System Security, February, Vol. 2, No. 1, pp 65–104.

Botha, R.A. and Eloff, J.H.P. (2001) ‘Separation of duties for access control enforcement in workflow environments’, IBM Systems Journal, Vol. 40, No. 3, pp.666–682.

Buyens, K., Win, B.D. and Joosen, W. (2009) ‘Resolving least privilege violations in software architectures’, Proceedings of the ICSE Workshop on Software Engineering for Secure Systems (ICSE/SESS’09), Vancouver, Canada, 19 May, pp.9–16.

Chen, L. and Crampton, J. (2007a) ‘Applications of the oriented permission role-based access control model’, Proceedings of the 26th IEEE International Performance Computing and Communications Conference, (IPCCC’07), pp.387–394.

Chen, L. and Crampton, J. (2007b) ‘Inter-domain role mapping and least privilege’, Proceedings of the 12th ACM Symposium on Access Control Models and Technologies (SACMAT’07), 20–22 June, Nice Sophia-Antipolis, pp.157–162.

Colantonio, A., Di Pietro, R. and Ocello, A. (2008) ‘A cost-driven approach to role engineering’, Proceedings of the ACM symposium on Applied computing (SAC’08), 11–13 June, Fortaleza, Ceara, Brazil, pp.2129–2136.

Cone, E.J. and Davis, J.M. (2008) Role Engineering for Enterprise Security Management, Artech House, Norwood, MA.

El Bakkali, H. and Hatim, H. (2009) ‘RB-WAC: new approach for access control in workflows’, The 7th ACS/IEEE International Conference on Computer Systems and Applications (AICCSA’09), 10–13 May, Rabat, Morroco, pp.637–640.

Ene, A., Horne, W., Milosavljevic, N., Rao, P., Schreiber, R. and Tarjan, R.E. (2009) ‘Fast exact and heuristic methods for role minimization problems’, Proceedings of the 13th ACM Symposium on Access Control Models and Technologies (SACMAT’09), 3–5 June, Stresa, Italy, pp.1–10.

Ferraiolo, D.F., Kuhn, D.R. and Chandramouli, R. (2007) Role-Based Access Control, 2nd ed., Artech House, Norwood, MA.

Liao, X., Zhang, L. and Chan, S.C.F. (2005) ‘Task-oriented access control model for WfMS’, Proceeding of the 1st International conference on Information Security Practice and Experience (ISPEC’2005), 11–14 April, Singapore, pp.168–177.

Lul, S. and Jiang, H. (2006) ‘RTFW: an access control model for workflow environment’, Proceedings of the 10th International Conference on Computer Supported Cooperative Work in Design (CSCWD’06), 3–5 May, Nanjing, China, pp.1005–1009.

Papenfus, C. and Botha, R. (2000) ‘An XML based approach to enforcing history-based separation of duty policies in heterogeneous workflow environments’, South African Computer Journal, Special Issue’00, No. 26, pp.2–68.

Perelson, S. and Botha, R.A. (2000) ‘Conflict analysis as a means of enforcing static separation of duty requirements in workflow environments’, South African Computer Journal, Special Issue’00, No. 26, pp.212–216.

Schlegelmilch, J. and Steffens, U. (2005) ‘Role mining with ORCA’, Proceedings of the 10th ACM Symposium on Access Control Models and Technologies (SACMAT’05), 1–3 June, Stockholm, Sweden, pp.168–176.

Sun, Y., Meng, X. and Yin, F. (2006) ‘A novel approach for role hierarchies in flexible RBAC workflow’, Proceedings of the 10th International Enterprise Distributed Object Computing Conference (EDOC’06), 16–20 October, Hong Kong, China, pp.488–491.

70 H. Hatim et al.

Thomas, R.K. and Sandhu, R.S. (1997) ‘Task-based authorization controls (TBAC): a family of models for active and enterprise-oriented authorization’, Proceedings of the IFIP WG11.3 Workshop on Database Security DBSec, 10–13 August, Lake Tahoe, California, USA, pp.166–181.

Vaidya, J., Atluri, V. and Guo, Q. (2007) ‘The role mining problem: finding a minimal descriptive set of roles’, Proceedings of the 12th ACM symposium on Access control Models and Technologies (SACMAT’07), 20–22 June, Nice-Sophia Antipolis, pp.175–184.

Wainer, J., Kumar, A. and Barthelmess, P. (2007) ‘DW-RBAC: a formal security model of delegation and revocation in workflow systems’, Information Systems, Vol. 32, No. 3, pp.365–384.

Wang, B. and Zhang, S. (2007) ‘An organization and task based access control model for workflow system’, Proceeding of the International Conferences on Asia-Pacific Conference and Web-Age Information Management (APWeb/WAIM’07), 16–18 June, Huang Shan, China, pp.485–490.

Wei, Y. and Shu, Q. (2007) ‘A delegation-based workflow access control model’, Proceeding of the First International Symposium on Data, Privacy and E-Commerce (ISDPE’07), 1–3 November, Chengdu, China, pp.478–483.

Wolter, C. and Schaad, A. (2007) ‘Modeling of task-based authorization constraints in BPMN’, Proceeding of the 5th International Conference on Business Process Management (BPM’07), 24–28 September, Brisbane, Australia, pp.64–79.

Wolter, C., Schaad, A. and Meinel, C. (2008) ‘Task-based entailment constraints for basic workflow patterns’, Proceedings of the 13th ACM Symposium on Access Control Models and Technologies (SACMAT’08), 11–13 June, Estes Park, CO, USA, pp.51–60.

Ye, C., Cheung, S.C. and Chan, W.K. (2006) ‘Publishing and composition of atomicity-equivalent services for B2B collaboration’, Proceedings of the 28th international conference on Software engineering (ICSE’06), 20–28 May, Shanghai, China, pp.351–360.

Zhang, D., Ramamohanarao, K. and Ebringer, T. (2008) ‘Permission set mining: discovering practical and useful roles’, Proceedings of the Annual Computer Security Applications Conference (ACSAC’08), 8–12 December, Hsinchu, Taiwan, pp.247–256.

enforcing access control in workflow systems with a task engineering approach

Documents