A Flexible Model Supporting the Speci cation and ... - Semantic Scholar

A Flexible Model Supporting the Speci cation and Enforcement of Role-based Authorizations in Work ow Management Systems Elisa Bertino, Elena Ferrari

Dipartimento di Scienze dell'Informazione Universita di Milano, Milano, Italy

fbertino,[email protected]

Abstract

In recent years, work ow management systems (WFMSs) have gained popularity both in research as well as in commercial sectors. WFMSs are used to coordinate and streamline business processes of an organization. Often, very large WFMSs are used in organizations with users in the range of several thousands and number of process instances in the range of tens of thousands. To simplify the complexity of security administration, it is a common practice in many business organizations to allocate a role to perform each activity in the process and then assign one or more users to each role, and granting an authorization to roles rather than to users. Typically the security policies of the organization are expressed as constraints on users and roles. a well-known constraint is separation of duties. Unfortunately, current role-based access control models are not adequate to model such constraints. To address this issue, in this paper, (1) we present a language to express authorization constraints as clauses in a logic program, (2) provide formal notions of constraint consistency, and (3) propose algorithms to check for the consistency of the constraints and to assign roles and users to the work ow tasks in such a way that no constraints are violated.

1 Introduction

Work ow management systems (WFMSs) are today used in numerous application domains including oce automation, nance and banking, healthcare, telecommunications, manufacturing and production, to run their day-to-day applications. A work ow separates the various activities of a given organizational process into a set of well de ned tasks [4]. The various tasks in a work ow are usually carried out by several users according to the organizational rules relevant to the process represented by the work ow. The stringent security requirements imposed by many work ow applications, like the above ones, call for suitable access control mechanisms. An access control mechanism enforces the secu-

Vijayalakshmi Atluri

MS/CIS Department, Rutgers University 180 University Avenue, Newark NJ 07102 [email protected]

rity policy of the organization, typically expressed as a set of authorizations. Quite often, security policies of a given organization are expressed in terms of the roles within the organization rather than individuals (e.g., only the president can pass/veto the bill). Roles represent organizational agents intended to perform certain job functions within the organization. Users in turn are assigned appropriate roles based on their quali cations. Specifying authorizations on roles is not only convenient but reduces the complexity of access control because the number of roles in an organization is signi cantly smaller than that of users. Moreover, the use of roles as authorization subjects avoids having to revoke and re-grant authorizations whenever users change their positions and/or duties within the organization. Furthermore, role-based authorization is particularly bene cial in work ow environments to facilitate dynamic load balancing when a task can be performed by several individuals. As a matter of fact, commercial WFMSs such as Lotus Notes and Action Work ow support role-based authorizations [4, 8, 9]. A common drawback of role-based authorization models used in current WFMSs (or even DBMSs) is that they are not capable of modeling authorization constraints on roles. A typical authorization constraint, which is very relevant and well-known in the security area, is separation of duties [11]. Under the principle of separation of duties, a complex action is decomposed into several smaller steps, which are executed by dierent roles. Even though separation of duties has been applied to computerized information systems, current WFMSs provide no support for it. However, because a work ow decomposes a complex activity into a number of smaller well-de ned tasks, we believe that separation of duties could naturally t into work ow models. As an example, consider a (simple) activity dealing with the payment by a check [11]. This activity can be modeled by a simple work ow consisting of three tasks:

task T1: a clerk prepares a voucher and assigns an

account; task T2: the voucher and account are approved by a

supervisor; task T3: a clerk issues the check; the clerk issuing the check must be dierent from the clerk who prepared the voucher.

R1

R2

R4

This example well illustrates the use of roles and both

static and dynamic separation of duties. Each task is

assigned a role; namely T1 and T3 must be executed by a role `clerk', whereas T2 by a role `supervisor'. Therefore, the various duties, and the corresponding authorizations, are statically separated by imposing that dierent roles execute dierent tasks. Dynamic separation of duties is exempli ed by the constraint that a particular clerk must not execute both tasks T1 and T3 for the same voucher. If no proper support is provided, constraints like separation of duties must be implemented as application code and embedded into the various tasks. Such an approach makes dicult, if at all possible, the speci cation and management of authorization constraints. In this paper we present a language for de ning constraints on role assignment and user assignment to tasks in a work ow. Such constraint language supports, among other functions, both static and dynamic separation of duties. Because the number of tasks and constraints can be quite large, a relevant issue is to provide some formal notions of constraint consistency and devise algorithms for consistency checking. In this paper, we show how such constraints can be formally expressed as clauses in a logic program, so that we can exploit all results available in the logic programming and deductive database area. A further contribution of this paper is the development of an algorithm for planning role and user assignments to the various tasks. To our knowledge this is the rst approach proposed to systematically address the problem of assigning roles and users to tasks in a work ow. Although the concept of roles is not new in paper based systems, speci cation of access control based on roles has received attention only recently [7, 10, 12]. The work by Jonscher et al. [7] describes a rolebased access control scheme for object-oriented data models. Sandhu et al. [12] present a framework of four role-base access control models. Both [7] and [12] recognize the need for constraints on roles; while [12] identi es several types of constraints, [7] models some constraints resulting from the separation of duties using activation con ict relation to re ect such constraints as the author of the paper cannot act as a referee, and association con ict relation to capture the notion of mutually exclusive roles. However, these attempts are not sucient to model all the constraints required in WFMSs, because they do not attempt to capture the history of events. The only signi cant work in this direction is due to Sandhu [11], in which he

R3

Figure 1: An example of role order introduces the notion of transaction control expression. However, this research does not focus on the problem of consistency checking. Moreover, none of the prior research attempts to specify access control in terms of the activities or tasks (although some preliminary eorts have been made in [13]) and therefore are not adequate for WFMSs. The remainder of the paper is organized as follows. Section 2 introduces preliminary notations. Section 3 categorizes the various types of constraints that can be speci ed on work ows. Section 4 provides a logical framework to express the various types of constraints. Section 5 presents an approach which rst examines the consistency of all the constraints and then comes up with an appropriate role and user assignment to every task in the work ow. Section 6 provides conclusions.

2 Preliminaries

In our model, as in most WFMSs, we make the assumption that a work ow consists of several tasks. A task can be executed several times within the same work ow. We call such occurrence of a given task T an activation of T. Each task is associated with one or more roles. These roles are the only ones authorized to execute the task. We refer to the association of roles with tasks in a work ow as work ow role speci cation. In the remainder, U, R and T denote the set of users, roles, and tasks in a given work ow, respectively. A user can be authorized to play several roles and a role may be played by several users. We assume that there is some mechanism in place that associates users with roles. Whenever a user tries to execute a task, the access control system checks whether there exists a role authorized to execute the task, and whether the user is authorized to play such a role. We assume that roles are related according to a global A common mechanism is to maintain a table consisting of users and the list of roles the users are authorized to play. Authorizations to play a role are granted by role administrators. These aspects, however, are not relevant for the development of the current paper, and we refer the reader to [2].

partial order. Such order usually re ects the organizational position of roles within a given organization. Let Ri ; Rj 2 R be roles. We say that Ri dominates Rj , denoted Ri Rj , if Ri precedes Rj in the ordering. If Ri and Rj are the roles associated with a given task, it means that Ri should be given higher priority over Rj when assigning a role to the task. The relation is re exive, antisymmetric and transitive. Figure 1 illustrates an example of role order; there is an edge from node Ri to node Rj , if Rj precedes Ri in the role order. For each task of the work ow the global order can be re ned by specifying additional local order relationships for roles for which there is no relationship in the global order. Let Ti be a task, and let RSi be the set of roles authorized to execute Ti . The partial local order for RSi is denoted as i . For example, suppose that RSi = fRi1 ; Ri2 g, and RSj = fRj1 ; Rj2 g, with Ri1 Ri2 in the global order. The global order can be re ned for task Tj by imposing Rj1 j Rj2 (or Rj2 j Rj1 ), because no order relationship is imposed between Rj1 and Rj2 in the global order. By contrast, no re nement of the role order can be performed for task Ti because the set of roles associated with task Ti is totally ordered by the global order. As a nal remark, note that if several roles are authorized to execute a task and no order for those roles is speci ed in the global and local orders, the task can be performed by any of these roles. For instance, if RSi = fRi1 ; Ri2 g and neither Ri1 i Ri2 nor Ri2 i Ri1 , then any user that can play either role Ri1 or role Ri2 can perform task Ti . A work ow role speci cation is formally de ned as follows.

De nition 2.1 (Work ow Role Speci cation) A work ow role speci cation is a set of task role speci cations fTRS1 ; TRS2; : : : TRSng, where each TRSi is a 3-tuple (Ti ; (RSi; i ); acti) where Ti 2 T is a task, RSi R is the set of roles authorized to execute Ti , i is a local role order relationship, and acti 2 IN is the number of activations of task Ti .

2

In the following we use the term work ow and work ow role speci cation as synonyms. Note from the above de nition, that we assume that the number of possible activations of each task within a work ow is known when the work ow role speci cation is given. Such number is used by the planner when generating the actual role assignments for the tasks. It can actually be considered the maximum number or the average number of expected activations. Because the planner will be re-activated during the work ow execution to deal with possible execution exceptions, it is not crucial that the number of activations given by the speci cation be the actual one. However, a correct estimate will reduce the planning overhead at run-time.

A work ow may have several work ow instances. We assume that each instance inherits the same work ow role speci cation from the work ow from which it is generated. We also assume that each task activation, within a work ow instance, is executed by a single user. Such user must belong to one of the roles authorized to execute the task in the work ow role speci cation. However, dierent activations of the same task within a work ow instance may be executed by the same user or dierent users, according to role authorization constraints speci ed for the work ow (see next section).

Example 2.1 W = f(T1; (fR1; R2; R3g; fg); 3); (T2; (fR1; R2 g; fg); 2); (T3; (fR2; R3g; fg); 4)g is an example of work ow role speci cation.y Throughout the paper we will use W as running example. Moreover, we will assume that roles R1, R2 and R3 are related according to the global role order depicted in Figure 1. 4

3 Constraints on role and user assignments

Constraints on role and user assignments to tasks in a work ow can be of several dierent types. We categorize them into three categories according to the time at which they can be evaluated: 1) Static constraints: these constraints can be evaluated without executing the work ow; 2) Dynamic constraints: these constraints can be evaluated only during the execution of a work ow, because they express restrictions based on the execution history of the work ow; 3) Hybrid constraints: these are constraints whose satis ability can be partially veri ed without executing the work ow.

Example 3.1 Consider the following constraints speci ed on the work ow of Example 2.1. C1

: At least three roles must be associated with the

work ow. C2: The same role must execute tasks T1 and T2. C3: Task T2 must be executed by a role dominating the role which executes task T3 . C4: If John belongs to role R1 and has performed task T1 , then he cannot perform T2 .z C5: If three activations of task T3 executed by the same role abort, then that role cannot execute task T3 any more. Constraint C1 is a static constraint since the number of roles associated with the work ow can be checked by simply considering the work ow role speci cation. fg

y ` ' denotes that no local role order is speci ed. z The separation of duties in our check processing example can

be speci ed as C2 and a constraint similar to C4 .

Pred.

Arity

role

2

user

2

Arg. type

RT ,TT UT ,TT

Meaning

If role(R ; T ) is true, then role R 2 RS ; If user(U ; T ) is true, then there exists R 2 RS such that U 2 R If belong(U ; R ) is true, then user U belongs to role R glb(R ; T ) is true if role R is the glb of RS , wrt the local order of T lub(R ; T ) is true if role R is the lub of RS , wrt the local order of T R R is true if R precedes R in the global role order i

2

UT ,RT

i

i

2

RT ,TT

2

RT ,TT

3

Arg. type

Meaning

UT ,TT ,NT

j

i

i

j

executer

3

RT ,TT ,NT

abort

2

TT ,NT

k

j

j

i

j

j

i

j

i

j

i

r

j

i

i

i

i

success

2

TT ,NT

j

i

(U ;T ; k) is true if the k-th activation of task T is executed by user U execute (R ; T ;k ) is true if the k-th activation of task T is executed by role R abort(T ;k ) is true if the k-th activation of task T aborts success(T ; k ) is true if the k-th activation of task T successfully executes executeu j

j

lub

executeu

j

i

glb

Arity

j

k

belong

Pred.

i

i

i

j

2

RT , RT

j

i

j

Table 2: Execution predicates

i

j

Table 1: Speci cation predicates Constraints C2, C3, and C4 are hybrid constraints. A preliminary consistency veri cation can be performed for these constraints without executing the work ow. If they are found inconsistent, they will certainly be not satis ed by the work ow execution. For instance, if the set of roles associated with task T1 is disjoint from the set of roles associated with T2 , constraint C2 would never be satis ed during work ow execution. If, however, the two sets are not disjoint it is necessary to verify, during the work ow execution, that whenever a role executes task T1 (T2), the same role also executes task T2 (T1 ). Finally, constraints C5 is a dynamic constraint since no check on its inconsistency can be performed without executing the work ow. 4

4 Formal model of constraints

In order to provide a semantic foundation for our constraint model and to formally prove consistency, we represent constraints as clauses in a general logic program [3]. We recall that clauses in a normal logic program may contain negative literals in their body. In the remainder, we formally de ne the language to express work ow constraints, we then present the notion of Constraint-Base, which is the logic program encoding the constraints of a given work ow, and discuss optimization and consistency issues.

4.1 The constraint speci cation language

We specify our constraint speci cation language by de ning the set of constants, variables and predicate symbols. We then de ne the rules that can be expressed in the language. In the following C denotes the set of constraints that can be associated with a work ow.

Constant Symbols: Every member of U, R, T , C , and IN.

Variable Symbols: There are ve sets of variable symbols ranging over the sets U, R, T , C , and IN,

denoted as VU , VR, VT , VC , and VIN , respectively. In the following we denote with UT (i.e., user terms) the set VU [ U. Similarly, RT, TT, CT, NT denote the sets VR [ R, VT [ T , VC [ C , and VIN [ IN, respectively.

Predicate Symbols: The set of predicate symbols con-

sists of ve sets: (1) a set of speci cation predicates

SP expressing information concerning the speci ca-

tion of a work ow; (2) a set of execution predicates

EP capturing the eect of a work ow execution; (3) a set of planning predicates PP expressing the re-

strictions imposed by the work ow constraints on the set of roles/users that can execute a work ow and information on constraint satis ability; (4) a set of comparison predicates CP capturing comparison operators. CP consists of the binary predicate =, whose arguments are elements in UT, RT, TT, NT, and binary predicates , , whose arguments are elements in NT; (5) a set of aggregate predicates AP capturing aggregate operators.x

Predicates belonging to SP , EP , PP , and AP are listed in Tables 1, 2, 3, and 4, respectively. A rule is an expression of the form: H A1 ; : : :An,not(B1); : : : not(Bm ), n; m 0 where H, A1; : : :; An, B1 ; : : :Bm are atoms and not is the negation by failure symbol. Rules of our language can be classi ed into a set of categories according to the predicate symbol they contain. In the following we illustrate each of these categories. x Aggregate predicates in

AP are those de ned by Das in [3].

Pred.

Arity

Arguments' type

count

2

conjunction of speci cation,execution or comparison literals,NT

avg

3

variable1, conjunction of speci cation, execution or comparison literals,NT

min

3


max

3


sum

3


Meaning

(W;n) counts the number of dierent answers of the query W and returns this value as n avg(x;W; n) computes the average of the values of variable x obtained from all the dierent answers of the query W , and returns this value as n min(x;W; n) computes the minimum of the values of variable x obtained from all the dierent answers of the query W , and returns this value as n max(x;W; n) computes the maximum of the values of variable x obtained from all the dierent answers of the query W , and returns this value as n sum(x;W; n) computes the sum of the values of variable x obtained from all the dierent answers of the query W , and returns this value as n count

Legend: 1

The variable is one of the bound variables of the conjunction of literals.

Table 4: Aggregate predicates

De nition 4.1 (Explicit Rule) An explicit rule is of

the form H , where H is either a speci cation or an execution atom. 2 Explicit rules are facts as their bodies are always empty. Explicit rules whose head is a speci cation atom express the work ow role speci cation, such as the roles assigned to each task and the local role order. These rules are automatically generated from the work ow role speci cation. Explicit rules whose head is an execution atom are generated either by the system during work ow execution, or by the planner to generate the role (user) assignments. For example, upon the execution of the k-th activation of task Ti either the rule abort(Ti ; k) , or success(Ti; k) is generated depending on whether the k-th activation of task Ti aborts or successfully executes. De nition 4.2 (Assignment Rule) An assignment rule is of the form H L1 ; : : :; Ln where H is either a must executeu, must executer cannot dou or a cannot dor atom, and Li is either a speci cation, execution, or comparison literal, or an aggregate atom, i = 1; : : :; n. 2 An assignment rule expresses the restrictions imposed by the work ow constraints on the set of roles/users that can execute a given task. Intuitively, assignment rules having must executer or must executeu as head state that a role/user must execute a given task in order to ensure constraint consistency. Assignment rules having cannot dor or cannot dou as head state that a role/user must be prevented from executing a given task.

De nition 4.3 (Static Check Rule) A static check rule is of the form stat checked(Ci) L1 ; : : :; Ln , where Ci 2 C , and Li is either a speci cation or comparison literal, or an aggregate atom, i = 1; : : :; n. Each literal appearing in an aggregate atom must be either a speci cation or a comparison literal. 2

A static check rule states that the satis ability of a work ow constraint can be veri ed without executing the work ow. These rules are automatically generated by the system for optimization purposes to avoid redundant checks at execution time.{

De nition 4.4 (Integrity Rule) An integrity rule is

of the form panic L1 ; : : :; Ln, where Li is either a speci cation, execution, or comparison literal, or an aggregate atom, i = 1; : : :; n. 2 Integrity rules are used to model the non-satis ability of a given constraint. Rules of our language can be further categorized into static and dynamic rules according to the time at which they can be evaluated.

De nition 4.5 (Static Rule) A static rule is either an explicit, assignment, static check or integrity rule such that all literals appearing in the rule body are either speci cation, aggregate or comparison literal. Each literal appearing in an aggregate atom must be either a speci cation or comparison literal. 2 { We

will elaborate on this aspect in subsection 4.3.

Pred.

Arity

cannot dou

2

Arg. type

UT ,TT

Meaning

(U ;T ) is true if task T cannot be assigned to user U cannot do (R ; T ) is true if task T cannot be assigned to role R must execute (U ; T ) is true if task T must be executed by user U must execute (R ; T ) is true if task T must be executed by role R stat checked(C ) is true if the satis ability of C can be veri ed without executing the work ow panic is true if there exists a work ow constraint which is not satis able cannot dou

i

j

j

2

cannot dor

RT ,TT

i

r

i

j

j

must executeu

2

UT ,TT

i

u

i

j

j

must executer

2

RT ,TT

i

r

i

j

j

stat checked

1

CT

i

i

rules may be necessary to encode a single constraint, throughout the paper we use the notation Ri;j to denote the j-th rule used to encode constraint Ci , i; j 2 IN.

Example 4.1 Consider the work ow of Example 2.1, the global role order in Figure 1, and the constraints of Example 3.1. CB(W) is as follows:

R1;1 : panic count(role(Ri; Tj ); n), n < 3 R2;1 : must executer (Ri ; T2 ) executer(Ri ; T1; k); executer(Ri ; T2; k); R2;2 : must executer (Ri ; T1 ) R3;1 : cannot dor (Ri ; T3 ) executer(Rj ; T2 ; k), Ri R3;2 : cannot dor (Ri ; T2 ) executer(Rj ; T3 ; k), Rj R3;3 : cannot dor (Ri ; T2 ) executer(Rj ; T3 ; k), Ri executer(Rj ; T2 ; k), Rj R3;4 : cannot dor (Ri ; T3 ) R4;1 :cannot dou (John,T2) belong(John,R1), executeu(John,T1; k) R5;1 :cannot dor (Rj ,T3 ) count(abort(T3; k), executer (Rj ,T3 ; k),n), n 3

6 6

; ; R ; R ; Rj

Ri j

i

i

panic

0

Table 3: Planning predicates Intuitively, static rules are those rules that can be evaluated without executing the work ow. They are used to encode the static constraints associated with a work ow. De nition 4.6 (Dynamic Rule) A dynamic rule is either an explicit, assignment, or integrity rule containing at least an execution literal. The execution literal can appear either explicitly or as argument of an aggregate literal. 2 Dynamic rules must be evaluated during the work ow execution. These rules are used to encode the dynamic and hybrid constraints.

4.2 Constraint-Base

We associate with each work ow W a Constraint-Base (CB), that is, a set of rules, speci ed in the constraint speci cation language, encoding the constraints de ned on the work ow. De nition 4.7 (Constraint-Base) Let W be a work ow. The Constraint-Base associated with W (written CB(W)), consists of a set of explicit, assignment, and integrity rules. The set of explicit rules are determined according to the conditions speci ed in Table 5. 2 We assume that each rule in the CB has a unique label assigned by the system upon its insertion. Since several

Moreover, let R1 = fJohn,Maryg, R2 = fAnn,Keng, = fAnn,Johng. According to the rules in Table 5, CB(W) contains the following explicit rules: R1 R2 , R2 R3 , role(Ri; T1) , i = 1; 2; 3, role(Ri; T2) , i = 1; 2, role(Ri; T3) , i = 2; 3, user(Ui; T1) , 8Ui 2 fJohn; Ann; Mary; Keng, user(Ui ; T2) , 8Ui 2 fJohn; Mary; Ann; Keng, user(Ui; T3) , 8Ui 2 fJohn; Ann; Keng, belong(Ui; R1) , 8Ui 2 fJohn; Maryg, belong(Ui; R2) , 8Ui 2 fAnn; Keng, belong(Ui; R3) , 8Ui 2 fAnn; Johng, glb(R1; T1) , lub(R3; T1) , glb(R1; T2) , lub(R2; T2) , glb(R2; T3) , and lub(R3; T3) . 4

R3

In order to completely de ne the notion of CB, a semantics must be assigned to it. We consider stable model semantics of logic programs with negation [5] to identify the models of a CB. The following proposition ensures the uniqueness of the model of a CB.

Proposition 4.1 Any CB is a strati ed normal program. Hence it has a unique stable model. We refer the reader to [2] for the formal proof. In the following we use M(CB) to denote the meaning of a CB with respect to the stable model semantics.

4.3 Enhancing the CB for optimization

The CB of a work ow encodes static constraints by a set of static rules, and hybrid and dynamic constraints by a set of dynamic rules. For some hybrid constraints, it is however possible to determine sucient conditions that can be veri ed statically for testing the satis ability (or non-satis ability) of the constraints. Sometimes a ner analysis on hybrid constraints can be performed to statically determine which are the roles (users) that when assigned to tasks do not satisfy the constraints. Similarly, it is sometimes possible to

Rule

R R role(R ,T ) user(U ,T ) belong(U ; R ) glb(R ;T ) lub(R ;T ) execute (R ;T ; k ) execute (U ; T ;k ) abort(T ; k ) success(T ; k ) i

j

i

j

i

j

i

j

i

j

i

j

r

i

j

u

i

j

i

i

Condition

8R ; R 2 R such that R precedes R in the global role order 8R 2 R, 8T 2 T such that R 2 RS 8U 2 U , 8T 2 T such that 9R 2 RS with U 2 R 8U 2 U , 8R 2 R such that U 2 R 8R 2 R, 8T 2 T such that R = glb(RS ) 8R 2 R, 8T 2 T such that R = lub(RS ) 8R 2 R, 8T 2 T , 8k 2 IN such that R executes the k-th activation of T 8U 2 U , 8T 2 T , 8k 2 IN such that user U executes the k-th activation of T 8T 2 T , 8k 2 IN such that the k-th activation of T aborts 8T 2 T , 8k 2 IN such that the k-th activation of T successfully executes i

j

i

i

j

i

j

j

i

j

j

k

i

j

i

j

i

j

j

i

j

i

j

i

j

i

k

j

i

i

i

j

i

i

i

i

i

j

Table 5: CB explicit rules statically determine which are the roles (users) for which it is mandatory to execute a given task in order to ensure constraint satis ability. The following example illustrates the discussion. Example 4.2 It is possible to statically verify that constraint C2 of Example 3.1 would never be satis ed if T1 is executed by role R3 , since R3 does not belong to the roles of task T2 . Therefore, role R3 can be pruned from the roles associated with T1. Similarly, if John does not belong to role R1, no further check on C4 at execution time is needed. Therefore, constraint C4 can be pruned from the CB. 4 Note that, static conditions for checking hybrid constraints are crucial in order to reduce the overhead of constraint checking at execution time. Therefore, we complement the CB with a set of optimization rules encoding static checks that can be performed on hybrid constraints. These rules are automatically generated by the system on the basis of the rules in the CB encoding hybrid constraints. Example 4.3 Consider the CB of Example 4.1. The following optimization rules are generated by the system: R2;3 : cannot dor (Ri ; T1 ) R2;4 : cannot dor (Ri ; T2 ) R3;5 :cannot dor (Ri ; T2 ) Rj

;

Ri

;

Ri

R3;6 : cannot dor (Ri ; T3 ) Rj

R4;2 : stat checked(C4) R4;3 : stat checked(C4) R4;4 : stat checked(C4)

role(Ri ; T1 ), not(role(Ri; T2 )); role(Ri ; T2 ), not(role(Ri; T1 )); role(Ri ; T2 ), lub(Rj ; T3 ), role(Ri ; T3 ), glb(Rj ; T2 ),

not(user(John,T1)); not(user(John,T2)) not(belong(John,R1)). 4

The result in Proposition 4.1 naturally extends to CBs containing also optimization rules. In the following with the term CB we refer to a CB complemented with the corresponding optimization rules.

4.4 CB consistency

Intuitively, a CB is consistent if and only if the constraints it encodes are satis able. The consistency of a CB is determined by computing and analyzing its model. The formal de nition of a consistency notion for a CB entails a number of dierent conditions to be satis ed by the model of CB. First, if predicate panic belongs to the model of CB, it means that at least one work ow constraint cannot be satis ed. Therefore, a rst consistency condition requires predicate panic not to belong to the model of a CB. Then, it is necessary to verify that the facts belonging to the model of CB do not express contradictory information. As an example, suppose that both must executer (R2,T1) and cannot dor (R2,T1) belong to the model of a CB. This means that the work ow constraints are inconsistent since no execution of task T1 would satisfy the constraints. Similar considerations apply to must executeu and cannot dou predicates. To check that no contradictory information is entailed by a CB, we compute for each task Ti in a work ow W, the set of roles/users which must be prevented/obliged to execute task Ti according to the rules in CB(W). These sets are as follows:

Denied Roles(Ti ) = SfRj j cannot dor (Rj ; Ti) 2 M(CB(W))g. Denied Roles(Ti ) represents the set

of roles that cannot execute task Ti according to the rules in CB(W); Obliged Roles(Ti ) = SfRj j must executer (Rj ; Ti) 2 M(CB(W))g. Obliged Roles(Ti ) denotes the set of roles that are obliged to execute task Ti according to the rules in CB(W); Denied Users(Ti ) = Sfu j cannot dou (u; Ti) 2 M(CB(W))g. Denied Users(Ti) is the set of users that cannot execute task Ti according to the rules in CB(W); Obliged Users(Ti ) = Sfu j must executeu(u; Ti) 2 M(CB(W))g. Obliged Users(Ti ) is the set of users

that are obliged to execute task Ti according to the rules in CB(W); It is therefore necessary to verify that the roles (users) for which is mandatory to execute a task, if any, belong to the set of roles (users) assigned to the task and are not included in the set of roles (users) which must not execute the task. Finally, it is necessary to verify that for each task there exists at least a user that, when assigned to the task, ensures constraint satis ability. The above requirements are formalized by the following de nition.

De nition 4.8 (Constraint-Base Consistency) Let CB(W) be the Constraint-Base of a work ow W. CB(W) is consistent if and only if the following conditions hold: panic 62 M(CB(W)); 8Ti of W: { If Obliged Users(Ti ) 6= ;, then: Obliged Users(Ti ) \ Denied Users(Ti ) = ;; Obliged Users(Ti ) fu j u 2 Rj ^ Rj 2 RSi g; { If Obliged Roles(Ti ) =6 ;, then: Obliged Roles(Ti ) \ Denied Roles(Ti ) = ;; Obliged Roles(Ti ) RSi ; Obliged Users(Ti ) fu j u 2 Rj ^ Rj 2 Obliged Roles(Ti )g; { If Obliged Users(Ti) = ; and Obliged Roles(Ti ) = ;, then: 9Rj 2 (RSi nDenied Roles(Ti )) such that: Rj n Denied Users(Ti) = 6 ;. 2

5 Consistency analysis and planning

In this section we present our methodology to assign roles and users to the tasks of a work ow according to the constraints encoded in the CB. First, the consistency of the CB must be veri ed; if the CB is inconsistent no assignment is generated. Then, if the CB is consistent, all assignments of roles/users to tasks that satisfy the constraints are generated. The various steps of our methodology are illustrated in Figure 2. Each step is performed by a speci c component of the authorization system [2]. A rst step, referred to as static analysis determines whether the static part of the CB, that is, the subset of the CB containing only static rules, is consistent according to De nition 4.8. If the check fails, the constraints speci ed for the work ow are inherently inconsistent, and therefore no assignment to tasks is generated. Thus the system

security ocer (or DBA or work ow designer) has to modify role assignments to tasks and/or the constraints. If the check succeeds, the pruning phase is executed. This phase modi es the work ow role speci cation to take into account the results of the static analysis phase. Moreover, the CB is modi ed to eliminate redundant rules. Pruning will make the execution of the subsequent phases more ecient. The planning phase receives the modi ed work ow and the modi ed CB generated by the pruning phase as input, and generates all possible roles/users assignments to tasks that satisfy the constraints. If no assignment can be generated, an error is returned to the system security ocer. To limit the number of choices to be evaluated by the planner, we make the assumption that all the tasks successfully execute. At run-time, constraints involving abort predicates are checked; if they are not satis ed, the planner is invoked again. The planner is also reactivated if the number of activations of a task exceeds the number stated in the work ow role speci cation. The run-time activation of the planner is denoted as run-time phase. In the remainder of this section, we discuss pruning, planning, and run-time phases. The static analysis phase is based on the consistency notions stated by De nition 4.8 (we refer the reader to [2] for the static analysis algorithm).

5.1 Pruning phase

The aim of the pruning phase is to modify the work ow speci cation according to the result of the static analysis phase in order to eciently execute the subsequent phases. The static analysis phase determines for each task a set of roles (users), if any, for which it is mandatory to execute the task (i.e., the sets Obliged Roles and Obliged Users de ned in subsection 4.4), and a set of incorrect roles and user assignments, that is, a set of roles and users that, when assigned to the task, do not satisfy the constraints (i.e., the sets Denied Roles and Denied Users). If Obliged Users and/or Obliged Roles are not empty, all the roles (users) which do not belong to these sets can be removed from the speci cation since their assignment to the task would violate the work ow constraints. If sets Obliged Roles and Obliged Users are empty, then the roles (users) belonging to Denied User (Denied Roles) are pruned from the set of roles and users that can be assigned to the task. Finally, based on the result of the static analysis phase, the pruning phase updates the CB by removing the dynamic rules which is no longer necessary to evaluate in the subsequent phases. An algorithm implementing the pruning phase can be found in [2].

Example 5.1 The pruned work ow role speci cation for the work ow role speci cation of Example 2.1 is:

system security officer GUI

Workflow Role Specification

Constraint Base

Static Analysis

Pruning

Pruned Workflow Role Specification

Pruned Constraint Base

Planner

Pruned Constraint Base

Assignment Graph

Run-time Phase

Figure 2: Phases in constraint speci cation analysis and enforcement Prun W = f(T1; (fR1; R2g; fg); 3); (T2; (fR1; R2g; fg); 2); (T3 ; (fR2; R3g; fg); 4)g, since R3 2 Denied Roles (T1 ). 4

5.2 Planning phase

This phase generates the set of possible assignments of roles and users to tasks so that all the constraints associated with the work ow are satis ed. This phase, intended to perform an initial plan, is executed before the work ow execution starts. Our approach to planning is based on the use of the CB as an hypothetical reasoner. For example, to determine whether the execution of the k-th activation of task Tj by a role Ri would violate the constraints, we insert into CB the facts, called assignment hypotheses, executer (Ri ; Tj ; k) and success(Tj ; k). We then formulate assignment hypotheses for all the subsequent tasks in the work ow and verify the consistency of the CB. We then remove the hypotheses executer (Ri ; Tj ; k) and success(Tj ; k) from the CB and consider another role for Tj . The planning thus generates all consistent assignment hypotheses. We begin with the role assignments to tasks. This is because when compared to the number of users, fewer

roles are typically assigned for each task. Because the roles are not many, performing a correct assignment is crucial. Once the role assignment has been planned, we assign users to each task. Therefore the planning phase consists of two sub-phases: the role planning phase and the user planning phase. Due to space limitations, we have not included in this paper the strategies and algorithms developed for the user planning phase. It is only important to remark that we do not perform always an exhaustive user planning. Some roles may have a large number of users authorized to play them. Then planning at the user level would become expensive. Several heuristics can be used to decide for which users to execute a user planning. Also, in some cases, the user planning may not even be executed. We refer the reader to [2] for a detailed description of the user planning phase. For the sake of simplicity, in the presentation we consider only the case in which all the activations of a task must be executed by the same role. In the algorithm, we therefore use a slightly dierent notion of consistency with respect to the one presented in subsection 4.4 in that we require, in addition to the conditions of De nition 4.8 that, for each task Ti in the work ow, Obliged Roles(Ti ) contains at most one element. We refer the reader to [2] for the extended version of the algorithm. In planning the role assignments we suppose that each task Ti is executed at most acti times, where acti is the number of activations speci ed in the work ow role speci cation. Role assignments are stored into a Role Assignment Graph, de ned as follows. De nition 5.1 (Role Assignment Graph) Let W = fTRS1 ; TRS2; : : : TRSn g be a work ow role speci cation with TRSi = (Ti ; (RSi; i ); acti), i = 1; : : :; n. The Role Assignment Graph of W (RAG(W)) is a labeled directed graph G = (V; E) de ned as follows: 1. Vertices. There is a vertex labeled (Ti ; Rj ), Ti 2 TRSi ; Rj 2 RSi i the assignment of role Rj to task Ti does not violate the work ow constraints. A vertex labeled (Ti ; Rj ) states that role Rj can be assigned to task Ti during the work ow execution. 2. Edges. There exists a directed arc from node (Ti ; Rj ) to node (Ti+1 ; Rk) if the assignment of role Rj to task Ti and the assignment of role Rk to task Ti+1 within the same work ow execution do not violate the constraints. 2

Note that nodes labeled (T1; Ri) do not have incoming arcs, whereas nodes labeled (Tn ; Ri) do not have outgoing arcs. Therefore, the role assignment graph is actually a forest. The root of each tree in the forest has label (T1 ; Ri).

Algorithm 5.1 The Role Planner

1) The pruned work ow Prun W = fTRS01 ; TRS02 ;: : : TRS0 g, where TRS0 = (T ; (Upd RS ; );act ) 2) The pruned Constraint-Base Prun CB(W ) OUTPUT: 1) FALSE if no role assignment satisfying the constraints can be generated; RAG(W ), otherwise. 1. Let BASE be the subset of Prun CB(W ) containing only explicit and dynamic rules 2. Let n be the number of tasks in Prun W 3. role assignment(1,n,;) 4. Discard all the paths of length less than n from RAG(W ) 5. If RAG(W ) is empty: return FALSE Procedure role assignment(current task,num task, current path) 1. i := current task 2. Repeat (a) Compute Obliged Roles(T ) and Denied Roles(T ), Temp RS := Upd RS (b) If Obliged Roles(T ) 6= ;: Temp RS := Obliged Roles(T ) else Temp RS := Temp RS n Denied Roles (T ) (c) Let Cand R := fR j R 2 Temp RS ^ R is unmarked ^ 6 9R 2 Temp RS such that R R g (d) If Cand R 6= ;: Let R be an element in Cand R, Mark R For k := 1 to act : Add to BASE execute (R ; T ; k) , and success(T ; k) If BASE is consistent: success := true, k := i ? 1 While k > 0 and success: Compute Obliged Roles(T ) and Denied Roles(T ) If Obliged Roles(T )6= ;: Let R be the unique element in Obliged Roles(T ) If current path[k].R 6= R : success := false else If current path[k].R 2Denied Roles(T ): success := false k := k ? 1 INPUT:

n

i

i

i

i

i

i

i

i

i

i

i

i

i

j

i

i

j

i

j

i

k

k

i

l

l

r

i

l

i

i

k

k

k

j

k

j

k

endwhile If success:

Add a node v0 to RAG(Prun W ) with label (T ;R ) current path[i] := (T ; R ) If i > 1: Let v be the element in V (RAG(Prun W )) such that label(v00 ) = current path[i ? 1] Add to E (RAG(Prun W )) (v ;v0 ) i

i

l

l

00

00

endif

endif endif If i < num task: role assignment(i + 1,num task,current path) endif For k := 1 to act : Remove from BASE the rules inserted by step (2d) i

Until 6 9 an unmarked role in Upd RS 3. Unmark all the roles in Upd RS , current path[i] := ; i

i

Figure 3: The role planner

j

(T3,R2)

(T1,R1)

(T1,R2)

(T2,R1)

(T2,R2)

(T3,R3)

(T3,R3)

Figure 4: The role assignment graph for the work ow of Example 2.1 Figure 3 reports the planning algorithm. In the algorithm, we use V (RAG(W)) and E(RAG(W)) to denote the set of nodes and arcs in RAG(W), respectively, and label(v) to denote the label of node v 2 V (RAG(W)). The main step of Algorithm 5.1 is the recursive procedure role assignment (step 3), which builds the role assignment graph of the input work ow. Note that, step (2c) of procedure role assignment ensures that a depth rst/leftmost traversal of the trees returned by the algorithm orders the various assignments according to the global role order. Therefore, at run-time, the assignment with the higher priority is always selected. Figure 4 shows the RAG generated by the Role Planner for the work ow of Example 2.1. The constraints associated with W are satis ed when T1 and T2 are executed by role R1, and T3 is executed either by R2 or R3, or when both T1 and T2 are executed by role R2, and T3 by role R3. The correctness of the Role Planner is stated by the following theorem.

Theorem 5.1 i) Algorithm 5.1 terminates. ii) There exists a path p = fv1; : : :; vng in RAG(W), with label(vi ) = (Ti ; Rj ), i = 1; : : :; n, i: 1) CB0 = Prun CB(W)[fexecuter (Rj ; Ti ; k) j i = 1; : : :; n; k = 1; : : :acti g [ fsuccess(Ti ; k) j i = 1; : : :; n; k = 1; : : :acti g is consistent and 2) Rj 2 Obliged Roles (Ti ), 6 ;, Rj 2 RSi n Denied Roles (Ti ), if Obliged Roles(Ti ) = otherwise, where Obliged Roles(Ti ), Denied Roles(Ti ) are computed with respect to CB0 . We refer the reader to [2] for the formal proof.

5.3 The run-time phase

The run-time phase is executed upon each task activation and termination. Upon invocation of the k-th activation of a task Tj in a work ow W, the run-time support of the authorization system is invoked to determine whether the user u, wishing to execute Tj under a certain role Ri, is authorized to do so, according to

RAG(W). The authorization check entails verifying all the following conditions: Role Ri must not have been disabled by the execution of tasks preceding Tj in the work ow. The execution of a task Tk by a role Rh disables Ri for the execution of Tj if in RAG(W) the node labeled (Tj ; Ri) is not connected through a path to the node labeled (Tk ; Rh). This condition ensures that tasks are executed by roles according to the plan generated by the planning phase. For example, referring to the RAG of Figure 4, the execution of task T1 by role R1 disables the execution of T2 by role R2. All roles with higher priority than Ri for the execution of Tj must not have available users.k The user must be authorized to play role Ri. If the user planning phase has been performed (see subsection 5.2), the user must be among the users that have been assigned to Tj . The execution of the k-th activation of Tj by u under role Ri must not make the CB inconsistent. This condition ensures that dynamic separation of duties is enforced. It is veri ed by adding the fact executeu(u; Tj ; k) and verifying the consistency of the CB. The run-time support of the authorization system implements other functions. It can generate the list of all users authorized to execute a certain task. Information about user authorizations can be useful, together with other information such as user load, to decide about user assignment to tasks. It can also generate the actual user assignments by selecting a user from the authorized roles, according to the RAG. Upon task termination, the run-time support of the authorization manager is invoked to record information about the task success or abort into the CB. If the task aborts, the planner is invoked again to determine whether the current plan needs to be modi ed. We refer the reader to [2] for details on the run-time phase and for all related algorithms.

6 Conclusions

Often, security policies of an organization, such as separation of duties, are expressed as constraints on users and roles. Unfortunately, current authorization models are not adequate to specify and evaluate such constraints. In this paper, we have rst identi ed the various types of constraints that can be speci ed on work ows { static, dynamic and hybrid { based on the k We assume that information about user availability is generated by the work ow management system and transmitted to the authorization system.

time at which they can be evaluated. While the static constraints can be evaluated even before the execution of the work ow, dynamic constraints can be only during the execution of the work ow. Hybrid constraints can be partially evaluated before the execution. Then, we have presented a language for specifying these various types of constraints, and devised algorithms to check for their consistency. To minimize the complexity of consistency checking during the execution of the work ow, we have presented a planning algorithm which generates all possible assignments of roles to tasks that satisfy authorization constraints. If at run-time tasks are executed by roles according to the plan, many dynamic constraints are automatically satis ed. Our approach thus requires only very few constraints to be checked during the execution of the work ow. Due to lack of space, we have limited ourselves by making several assumptions, which we have pointed out in the paper. A full version of the paper is available in [2]. Future work includes: the modeling of temporal and event-based constraints, the support of more complex models of roles and the integration with advanced authorization models such as the one presented in [6].

References

[1] V. Atluri, and W-K. Huang. An Authorization Model for Work ows. In Computer Security Esorics'96, LNCS No.1146, pages 44-64, 1996. [2] E. Bertino, E. Ferrari, and V. Atluri. A Flexible Model supporting the Speci cation and Enforcement of Role-based Authorizations in Work ow Management Systems. Technical Report, Department of Computer Science, University of Milano, January 1997. [3] S.K. Das. Deductive Databases and Logic Programming. Addison-Wesley,1992. [4] D. Georgakopoulos, M.Hornick, and A. Sheth, Overview of Work ow Management: From Process Modeling to Work ow Automation Infrastructure. Distributed and Parallel Databases, pages 119-153, 1995. [5] M. Gelfond and V. Lifschitz. The Stable Model Semantics for Logic Programming. In Proceedings of the 5th International Conference on Logic Programming, pages 1070{1080, Cambridge, Massachusetts, 1988. [6] S. Jajodia, P. Samarati, V. Subrahamanian and E. Bertino. A Uni ed Framework for Enforcing Multiple Access Control Policies. In Proceedings of the 1997 ACM-SIGMOD International Conference on Management of Data, Tucson, AZ, May 12-16,

1997.

[7] D. Jonscher, J.D. Moet and K.R. Dittrich. Complex Subjects or: The Striving for Complexity is Ruling our World. In Database Security VII: Status and Prospects, pages 19-37, North Holland, 1994. [8] Lotus Notes Administrator's Reference Manual, Release 4. Lotus Corporation, 1996. [9] R. Medina-Mora, H. K.T. Wong and P. Flores. ActionWork owT M as the Enterprise Integration Technology. Bulletin of IEEE Technical Committee on Data Engineering, 16(2): 49-52, 1993. [10] Proceedings of the First ACM Workshop on Role Based Access Control, 1996. [11] R. Sandhu. Separation of Duties in Computerized Information Systems. Database Security IV: Status and Prospects, pages 179-189, North Holland, 1991. [12] R. Sandhu et al. Role-based Access Control Models. IEEE Computer, pages 38-47, February, 1996. [13] R. Thomas and R. Sandhu. Task-based Authorization: A Research Project in Next-generation Active Security Models for Work ows. NSF Workshop on Work ow and Process Automation in Information Systems: State-of-the-Art and Future Directions,

May, 1996.