Download - Types for task-based access control in workflow systems

IETdoi

www.ietdl.org

Published in IET SoftwareReceived on 4th August 2007Revised on 6th March 2008doi: 10.1049/iet-sen:20070098

ISSN 1751-8806

Types for task-based access control inworkflow systemsY. Lu1 L. Zhang2 J. Sun2

1College of Software, Shenzhen University, Shenzhen 518060, People’s Republic of China2Key Laboratory for Information Security of Ministry of Education, School of Software, Tsinghua University, Beijing 100084,People’s Republic of ChinaE-mail: [email protected]

Abstract: Task-based access control (TBAC) is a flexible security mechanism, which has been widely implemented inworkflow management systems. In TBAC, permissions are assigned to tasks and users can only obtain thepermissions during the execution of tasks. The authors aim at developing a method for formalising and analysingsecurity properties of workflow systems under TBAC policy. To achieve this goal, the authors first present WFPI,workflow p-calculus. By adding task execution and submission primitives, and tagging each agent with itsexecuting and distributing tasks, WFPI can flexibly represent the concepts and elements in workflow systems.Then, based on WFPI, a type system is proposed to ensure that the well-typed workflow systems can abide bythe TBAC policy at run time, by avoiding run-time access violations. To the best of one’s knowledge, the presentresearch is the first attempt to study workflow access control by process calculus and types.

1 IntroductionWorkflow management is a fast evolving technology which isincreasingly being exploited by businesses in a variety ofindustries. Its primary characteristic is the automation ofprocesses involving combinations of human and machine-based activities [1]. A workflow consists of a set of tasks, andtheir order of invocation and information flow, according tocontrol flow dependencies. In the workflow system, the taskshould be carried out by a legitimate user with authorisedactions according to the workflow security policies. Accesscontrol is an important security mechanism to ensure datasecurity in workflow management systems (WfMSs) [2].Several workflow access control models have been proposed toprotect data and resources in WfMSs [3–7]. The essence ofthese models lies in task-based access control (TBAC). InTBAC, permissions are assigned to tasks and users can onlyobtain the permissions during the execution of tasks. Oncethe user completes and submits the task, it no longerpossesses the permissions to access the resources related withthe task. TBAC is a flexible and dynamic access controlmechanism: the user’s permissions can change dynamically byits status during the execution of the workflow processes.

Softw., 2008, Vol. 2, No. 5, pp. 461–473: 10.1049/iet-sen:20070098

Despite the importance of workflow access control, littleeffort has been taken on analysing the security properties ofworkflow systems, because of the lack of appropriate formalmethods. In this paper, we aim at developing such amethod to analyse whether there exist unauthorisedaccesses in workflow systems before the running ofworkflow processes. To achieve this goal, we first presentWFPI, workflow p-calculus, which extends the p-calculusin two aspects. First, systems are composed of agents. Anagent m[P]j has three parts: name m to denote its identity,process P to denote its behaviours and task set j to denoteits executing and distributing tasks. Users, task nodes andresources in workflow systems can be formalised by agents.Secondly, we add task execution primitives (exec and exec)and task submission primitives (subm and subm) to denotethe specific concepts in workflow systems. The task set j

can be changed by these primitives according to reductionrules. By these extensions, WFPI can flexibly represent theconcepts and elements in workflow systems.

To analyse the security properties of the workflow system,we propose a type system to ensure that the specified TBACpolicy can be abided by. By subject reduction, the well-typed

461

& The Institution of Engineering and Technology 2008

46

&

www.ietdl.org

system can abide by the specified TBAC policy at run time,by avoiding two kinds of run-time access violations: the user’sattempt to execute the tasks without proper authorisations andto access resources without corresponding permissions.

This paper is organised as follows. Section 2 gives a briefintroduction to related background and our motivation.Section 3 describes the formal syntax and semantics of theWFPI calculus. Section 4 presents a type system to preventthe unauthorised access according to TBAC policy. Section5 describes the related work. Section 6 concludes our workand proposes further work.

2 Background and motivation2.1 Workflow

Workflow is the automation of a business process, duringwhich documents, information or tasks are passed from oneparticipant to another for action, according to a set ofprocedural rules [1]. Workflow process defines thedependencies between tasks. The dependencies can besequential, and-split, and-join, or-split, or-join, choice,parallel and so on. A task (or activity) is a description of apiece of work that forms one logical step. These tasks areexecuted by multiple collaborating users (human beings ormachine agents). A user performs the work represented byworkflow tasks by accessing resources. The relationshipsbetween users, tasks and resources can be defined by accesscontrol rules.

As Fig. 1 shows, a workflow may be characterised as twostages in Wf MSs: the build time and the run time. Inbuild time, the system administrator defines workflowprocesses and access control rules (or policies), in textual or

2The Institution of Engineering and Technology 2008

graphical form. The system administrator can also verifythe correctness and consistence of these definitions in thisstage. In run time, each workflow process can beinstantiated to several workflow instances. Each instancerepresents a separate execution case of the workflow. Tasksare also instantiated to task instances. Task instances arescheduled according to the dependencies between them.For each task instance, a user is selected from the possibletask executors to perform the work represented by this taskinstance. The user may access the workflow data andresources by means of application tools to finish its task.Whether the user can access these data and resources aredecided by the predefined access control policies in theaccess check module.

2.2 Task-based access control

Authorisation and access control are important mechanismsto ensure data security in Wf MSs. It defines which usercan execute the tasks and which user can access theresources. We define a general TBAC model for Wf MSs.

Definition 1: The TBAC model is composed of thefollowing components:

US: the set of users. A user may be human, machine agent,role or web service.

TS: the set of tasks.

TD: the set of task distributors.

RS: the set of resources (or objects). The set of operations onthe resources is defined as OP.

Figure 1 Framework of WFMS

IET Softw., 2008, Vol. 2, No. 5, pp. 461–473doi: 10.1049/iet-sen:20070098

IETdo

www.ietdl.org

PS: the set of permissions. PS # 2RS�OP. Permissions areprivileges to access the resources. They are defined as theoperations on the resources in RS.

TDA (task distribution assignment): TDA # TD � TS.(di, tj)[ TDA denotes that di can distribute the task tj tousers for execution.

UTA (user task assignment): UTA# US � TS.(ui, tj)[ UTA denotes that ui can execute task tj.

TPA (task permission assignment): TPA# TS � PS.(ti, pj)[ TPA denotes that task ti has permission pj.

By this model, users are related to tasks, whereas tasks arerelated to permissions. A user that is executing a task canobtain the permissions related to that task. Once the usercompletes and submits the task, it cannot obtain thepermissions related to that task any longer. TBAC is aflexible and dynamic access control mechanism: the user’spermissions can change dynamically by its status during theexecution of workflow processes.

A security policy is a statement that partitions the states ofthe system into secure (or authorised) states and non-secure(or unauthorised) states. According to the TBAC model,we can define the security policy in Wf MSs.

Definition 2: A TBAC policy for a workflow system can bedefined as tuple (TDA, UTA, TPA) according to the TBACmodel.

Example 2: Fig. 2 illustrates a purchase order process which isdescribed by business process execution language (BPEL)specification in [8]. It includes six tasks. After receiving thepurchase order from a customer, the process will select ashipper for the product. Then, the final price for the orderis calculated by adding the product price and the shipping

Softw., 2008, Vol. 2, No. 5, pp. 461–473i: 10.1049/iet-sen:20070098

price. Meanwhile, the shipment schedule and theproduction schedule for the order are also arranged. Whenthese concurrent paths are completed, invoice processingcan proceed and the invoice is sent to the customer.

Fig. 2 also illustrates the users and permissions related to eachtask. There are four users in the system. User Ua, whoprovides the customer interaction service, can execute taskT1 and T6. User Ub, who provides the invoice service, canexecute task T2 and T4. User Uc, who provides theshipping service, can execute task T3. User Ud, whoprovides the production scheduling service, can execute taskT5. There are four resources in the system: p1 (purchaseorder), p2 (shipping information), p3 (shipping schedule)and p4 (invoice). Permissions are defined as reading orwriting on these resources.

Formally, the TBAC policy S1 for this example can bedefined as follows

S1 ::¼ (TDA:{(A1, T 1), (A2, T 2), (A3, T 3), (A4, T 4),

(A5, T 5), (A6, T 6)},

UTA:{(Ua, T 1), (Ua, T 6), (Ub, T 2), (Ub, T 4),

(Uc, T 3), (Ud , T 5)},

TPA:{(T 1, w p1), (T 2, r p1), (T 2, w p2), (T 3, r p2),

(T 3, w p4), (T 4, r p2), (T 4, w p3), (T 5, r p1),

(T 5, r p3), (T 6, r p4)})

2.3 Motivation

During the running of process instances in the workflowsystem, there may exist two kinds of access violations ofTBAC policy:

1. Unauthorised execution of tasks. The user attempts toexecute tasks without proper authorisations.

Figure 2 Purchase order process

463


46

&

www.ietdl.org

2. Unauthorised access of resources. The user attempts toaccess resources without corresponding permissions.

The above access violations can be prevented in run time by aworkflow engine and an access check module. During therunning of each process instance, only the workflow enginewill schedule the authorised users to execute the taskaccording to the access control policy. Thus, it can preventthe unauthorised execution of tasks. The access checkmodule can reject the unauthorised accessing of theresources according to the access control policy. Thus, itcan prevent the unauthorised accessing of resources.

Although these violations can be checked and excluded bythe workflow engine and the access check module during therunning of process instances, there exist some disadvantagesfor these run-time mechanisms to prevent the access violations:

1. Some users require specific resources to complete theirtasks. If the access control policy is not configured correctlyand the system rejects these specific access requests, theseusers cannot finish their jobs successfully. This may result infailures, exceptions or deadlocks for these process instances.

2. The access check procedure can be time consuming andmay influence the performance of workflow systems,especially in large systems with hundreds of users andthousands of resources.

Thus, it is meaningful if we can provide some analysis methodsand tools to check these access violations before the running of


process instances. Only after the system is analysed and ensuredas secure, the process can be instantiated and executed. By this,the disadvantages above can be avoided.

2.4 Our solution

Fig. 3 shows the roadmap of our solution. It includes fiveparts in the build and analysis time: process definition,policy definition, formalisation, type analysis and feedback.In the build time, the administrator defines workflowprocess according to the business requirements and definesthe access control policy according to the securityrequirements. In the analysis time, the administrator cancheck the consistency between the workflow process andaccess control policy. It includes the following steps:

1. Formalisation: Formalise the elements in the workflowsystem, including their behaviours and relationships. Thefollowing elements must be represented by the formalmethod:

† Elements in the workflow process: including processes,tasks and task relationships.

† Elements in access control: including users, resources, userexecuting tasks, user submitting tasks, user accessingresources and so on.After the formalisation, the dynamic behaviours of theformalised system must be able to represent the run-timebehaviours of the workflow system, including legalbehaviours and illegal behaviours.

Figure 3 Framework of security analysis by typing systems


IETdo

www.ietdl.org

2. Type analysis: Utilise typing rules to check whether theuser violates the TBAC policy in the workflow system. Ifthe system cannot be well-typed, there may existinconsistencies in the workflow system. The administratorcan obtain the feedback information about theseinconsistencies. Then, the administrator can adjust theaccess control rules or workflow process to resolve theinconsistencies. After the adjustment, the system should beanalysed again.

If the system can be well-typed in the analysis time, we canensure that the workflow system will always abide by theTBAC policy during run time. Then the workflow processcan be instantiated by the workflow engine and executed bythe users in run time.

3 Calculus of WFPI3.1 Syntax

The syntax of WFPI calculus is given in Table 1. Thecalculus is an extension of p-calculus [9, 10]. It includesthe definition of the following terms: names, processes,agents and systems.

Names can be used as channel names, task names, taskinstance names, agent names or variable names. The set oftask names is denoted as T. The set of task instance namesis denoted as I.

As in p-calculus, processes can be defined as inactiveprocess, parallel composition, replication, name restriction,input prefix, output prefix and match prefix. We add fourworkflow primitives to describe the specific concepts inworkflow systems. exec t(i) means that the agent attemptsto execute task instance i of task t and to obtain thepermissions of t. exec t(i) means that the agent attempts todistribute task instance i of task t. subm t(i) means that theagent attempts to submit task instance i of task t. subm t(i)means that the agent waits for other agents to submit taskinstance i of task t.

A system consists of parallel composition agents that canshare private channels, using the operator j and n.

An agent m[P]j consists of three parts: an agent name m todescribe the name of the agent, a process P to describe thebehaviours of the agent and a task set j # T � I� fkl,()gto denote the executing and distributing tasks and instancesof the agent. The elements of j is denoted as tkil and t(i).tkil means that the agent has distributed the task instance iof task t. t(i) means that the agent has executed the taskinstance i of task t and can obtain the permissions of taskst. We use ji to denote the task instances in j, jet to denotethe executing tasks and jdt to denote the distributing tasks.Formally, ji ¼ {i [ I j 9t(tkil [ j_t(i) [ j)}: jet ¼ {t [T j 9i(t(i) [ j)}:jdt ¼ {t [ T j 9i(tkil [ j)}.


3.2 Reduction semantics

The reduction semantics describes the dynamic behaviours ofthe calculus. We define the reduction semantics by structuralcongruence and the reduction relation as in p-calculus.Structural congruence equates terms that describe the samesystem. The structural congruence relation ; is the leastcongruence that is closed under the rules of the Table 2.We use fv(A) to denote the set of free variables in A.

The reduction relation is defined by the rules in Table 3. Theprocedures of communication are denoted by two rules: rule(R-ExtCom) for communication between two agents and rule(R-IntCom) for communication within an agent. In rule (R-ExtCom), agent m attempts to send the message v to channela and simultaneously agent n attempts to receive a messagefrom channel a. After the reduction, the message v is receivedby agent n. The explanation of rule (R-IntCom) is similar.

Rule (R-Exec) denotes the procedure of task distribution.Agent m attempts to distribute the task instance i of task tand simultaneously agent n attempts to execute task t.After reduction, agent n adds t(i) into its task set j0,

Table 1 Syntax of WFPI calculus

Names: a, b, .., .., m, n . . ., x, y, z [N

tasks: r, s, t [ T T # N

task instances: i, j, k [ I I # Nj # T � I � fkl,()g

Processes:

P, Q ::¼ Nil inactive process

PjQ parallel

!P replication

(ne)P name restriction

a(x).P input

akvl.P output

if x ¼ y then Pelse Q

matching

exec t(i).P executing task

exec t(i).P distributing task

subm t(i).P submitting task

subm t(i).P waiting for submission

Systems

A, B ::¼ 0 empty system

m[P]j agent

A j B composition

(ne)A restriction

465


46

&

www.ietdl.org

denoting that agent n is executing task instance i and canobtain the permissions defined on t. Agent m adds tkil intoits task set j, denoting that agent m has distributed thetask instance i of task t. Rule (R-Subm) denotes theprocedure of task submission. In this rule, agent n mustsubmit the task t simultaneously on its parallel sub-processes. The other rules are standard.

3.3 Formalisation

A workflow system can be formalised by WFPI calculus bythe following rules:

Table 2 Axioms for structural congruence

Aj0 ; A (S-AId)

AjB ; BjA (S-ACom)

(AjB)jC ; Aj(BjC) (S-AAss)

(ne)AjB ;ne(AjB) if e � fv(B) (S-ARes)

(ne)(y f )A ; (nf )(ne)A (S-AResC)

m[(ne)P]j ; (ne)m[P]j (S-LocCh)

m[PjNil]j ; m[P]j (S-PId)

m[PjQ]j ; m[QjP]j (S-PCom)

m[(PjQ)jR]j ; m[Pj(QjR)]j (S-PAss)

m[(ne)PjQ]j ; m[ne(PjQ)]j if e � fv(Q) (S-PRes)

m[(ne)(nf )P]j ; m[(nf )(ne)P]j (S-PResC)

m[!P]j ; m[Pj!P]j (S-PRepl)

m[exec t(i).PjQ]j ; m[exec t(i).P]j jm[Q]j if ji ¼ø

(S-ASplit)

Table 3 Rules for reduction relation

(R-ExtCom) m[akvl.P j R]j j n[a(x).Q j S]j0 ! m[P j R]j jn[Qfv/xg j S]j0

(R-IntCom) m[ak vl.P j a(x).Q j R]j! m[P j Qfv/xg jR]j

(R-Exec) m[exec t(i).P j R]j j n[exec t(x).Q]j0

! m[P j R]j<{tkil} j n[Q{i/x}]j0<{ t(i)}

(R-Subm) m[subm t(i).P j R]j j n[subm t(i).Q1

j. . . j subm t(i).Qn]j0

! m[P j R]j�{tkil} jn[Q1 j . . . j Qn]j0�{t(i)}

(R-Eq1 ) m[if x ¼ y then P else Q]j! m[P]jif x ¼ y

(R-Eq2 ) m[if x ¼ y then P else Q]j! m[Q]jif x = y

(R-Par) A! A0

AjB! A0jB(R-Res)

A! A0

(ne)A! (ne)A0

(R-Struct) A ; A0 A0 ! B0 B0 ; B

A! B


1. The tasks and task instances are represented by names.The task distributors are represented by agents. The taskrelationships are represented by channels.

2. The users and resources are represented by agents. Thepermissions on the resources are represented by channels.

3. The relationships of executing and submitting tasks canbe represented by task execution and submission primitives.

4. Workflow processes can be represented by systemsconsisting of agents.

By these rules, example 1 can be formalised by the followingsteps:

1. The resources are formalised as resource agents. Forresource p1, it can be represented by agent p1. Thepermissions on p1 can be represented by channel w_p1 andr_p1. A user can write data to p1 by channel w_p1. Toread data from p1, the user must send the return addressret_addr to channel r_p1. The data in p1 can be sent byret_addr to the requested user. The resources p2, p3 and p4can also be represented in this manner

p1:: ¼ p1[!w p1(po):Pj!r p1(ret addr):P 0]{}

2. The task nodes are formalised as task agents. Agent A1distributes task T1 to users at first. The restriction (n ia)guarantees that each instance of task T1 will have adifferent task instance identifier. After A1 receives thesubmission, it will notify agent A2 by channel b2. Theother task nodes are represented in the same way

A1 ::¼ A1[n ia(execT 1(ia):submT 1(ia):b2kl)]{}

A2 ::¼ A2[b2():n ib(execT 2(ib):submT 2(ib):(b3kljb4kl))]{}

A3 ::¼ A3[b3():n ic(execT 3(ic):submT 3(ic):b6kl)]{}

A4 ::¼ A4[b4():n id (execT 4(id ):submTd (id ):(b5kljb7kl))]{}

A5 ::¼ A5[b5():n ie(execT 5(ie):submT 5(ie):b8kl)]{}

A6 ::¼ A6[b6():b7():b8():n ig(execT 6(ig):submT 6(ig))]{}

3. The users are formalised as user agents. Suppose theusers are represented by the following agents:

Ua ::¼ Ua[!(exec T 1(xa) � rec order(po):w p1kpol:subm

T 1(xa))j !(exec T 6(xg):r p4kr1l:r1(invoice):

replykinvoicel:subm T 6(xg))]{}

Ub ::¼ Ub[!(exec T 2(xb):r p1kr2l:r2(po):shipper():

w p2kshpinfol:subm T 2(xb)) j !(exec T 4(xc):

r p2kr3l:r3(shpinfo):w p3kshpschl:subm T 4(xc))]{}


IETdo

www.ietdl.org

Uc ::¼ Uc[!(exec T 3(xd ):r p1kr4l:r4(po):r p2kr5l:

r5(shpinfo):price calculate() � w p4kinvoicel:subm T 3(xd ))]{}

Ud ::¼ Ud[!(exec T 5(xe):r p1kr6l:r6(po):r p3kr7l:

r7(shpsch):w p3kprodschl:subm T 5(xe)) j !

(exec T 3(xh):r p1kr8l:r8(po):subm T 3(xh))]{}

Agent Ua attempts to execute task T1 and T6. When itexecutes task T1, it first receives the purchase order pofrom channel rec_order. Then, it writes po to channelw_p1. After this, it will submit task T1. When it executestask T6, it will read the invoice information from r_p4 andthen send the invoice information by channel reply.

Agent Ub attempts to execute tasks T 2 and T4. When itexecutes task T 2, it first reads the purchase order fromchannel r_p1. Then, it can select the shipper and write theshipping information to channel w_p2. When it executestask T4, it will read the shipping information from channelr_p2 and then write the shipping schedule to channel w_p3.

Agent Uc attempts to execute task T 3. It will read thepurchase order from channel r_p1 and the shippinginformation from channel r_p2. Then, it will calculate thetotal price of the purchase order and save the invoiceinformation on channel w_p4.

Agent Ud attempts to execute tasks T5 and T3. When itexecutes task T5, it will read the purchase order from channelr_p1 and the shipping schedule from channel r_p3, then, itwill arrange the production schedule and write theproduction schedule prodsch to channel w_p3. When itexecutes task T 5, it will read po from channel r_p1.

4. The reduction semantics of these agents can representthe dynamic behaviours of the workflow system

A1 j A2 j A3 j A4 j A5 j A6 j Ua j Ub j Uc j Ud j p1 j p2

j p3 j p4

¼ A1[n ia(exec T 1(ia):subm T 1(ia):b2kl)]{} j

Ua[exec T 1(xa):Q] j � � � (A1 is distributing task T 1 to Ua)

! A1[subm T 1(ia):b2kl]{T 1kial} j Ua[w p1kpol:Q0]{T 1(ia)}

j p1[!w p1(po):P]{} � � � (Ua is accessing resource

p1 by writing po to w p1)

! � � �

! A1[subm T 1(ia):b2kl]{T 1kial} j Ua[subm T 1(ia)]{T 1(ia)}

j � � � (Ua is submitting task T 1to A1)


! A1b2kl]{}A2[b2():R] j � � � (A1is notifying A2 to proceed)

! A2[exec T 2(ib):R0]{} j � � �

4 TypesThe unauthorised access exists in the workflow system thatwe have formalised in Section 3.3. For example

Uc[r p1kr4l:P]{T 3(ic)} j p1[!r p1(ret addr):Q]{}

! Uc[P]{T 3(ic)} j p1[Q{r4=ret addr}]{} j p1[!r p1(ret addr):

Q]{}

Agent Uc reads data from channel r_p1. It will be consideredan unauthorised access under TBAC policy S1, because S1

does not allow users with task T 3 to access r_p1. Toformally define what an unauthorised access is, we mustfirst define a run-time error, which means that an agentwill violate the access control policy during run time. Then,we define typing rules. An agent with an unauthorisedaccess will be judged as an ill-typed agent by these typingrules. By the subject reduction theorem, we can guaranteethat well-typed systems never violate the specified TBACpolicy during run time.

4.1 Run-time errors

The run-time errors under the TBAC policy S are defined inTable 4. Run-time errors are generated in the followingpossible ways:

1. An agent attempts to access the protected channelswithout the corresponding permissions in TPA policy (ruleE-Rcv, E-Snd). Channel a is the protected permission(premise a [ PS). Agent m wants to receive data fromchannel a (rule E-Rcv) or to send data to channel a (ruleE-Snd), but all its executing tasks in j do not possess suchpermissions (premise 96 t [ jet(t, a) [ TPA).

2. An agent attempts to execute or submit the tasks withoutproper authorisations in UTA policy (premise (m, t) � UTAin rule E-Exec and E-Subm).

3. An agent attempts to distribute the tasks without properauthorisations in TDA policy (premise (m, t) � TDA inrule E-Distr and E-AlSubm).

4.2 Typing rules

The syntax of types is defined as the following

Message type MT ::¼ BT j agt(hd, he) j CT j tsk j ins

Channel type CT ::¼ ch(ha, MT)

Type T ::¼ MT j CT j VT

467


46

&

www.ietdl.org

Table 4 Run-time errors under TBAC policy S

a [ PS ^ 96 t [ jet(t, a) [ TPA

m[a(x):P]j 7! err

E-Rcv a [ PS ^ 96 t [ jet(t, a) [ TPA

m[akxl:P]j 7! err

E-Snd

(m, t) � UTA

m[exec t(i):P]j 7! err

E-Exec (m, t) � UTA

m[subm t(i):P]j 7! err

E-Subm

(m, t) � TDA

m[exect(i):P]j 7! err

E-Distr (m, t) � TDA

m[subm t(i):P]j 7! err

E-AlSubm

A 7! err

AjB 7! err

E-Par A 7! err

(ye)A 7! err

E-Res

A ; B B 7! err

A 7! err

E-Struct

We use hd, he andha to denote the distributable tasks,executable tasks and accessible tasks. hd, he andha aresubsets of task name set T. Type BT represents the basictypes, such as Boolean, int and so on. Type agt(hd, he) canbe assigned to an agent name, which has the distributabletasks of hd and executable task of he. Type ch(ha, MT)can be assigned to a channel name, which can be accessedby tasks in ha and can be used to transmit messages of typeMT. If ha ¼1, type ch(fg, MT) can be assigned to achannel name, which has not been protected by TBACpolicy and can be accessed by any agents withoutrestriction. VT is the type variables. Different type variablesare denoted by T1, T2, T3 and so on.

A typing environment G is a partial mapping from N intotypes. We define dom(G) as the domain of G and G (x) as thetype of x. G can be extended as

G, x:T ¼ G < {x:T} where x � dom(G)

The typing judgments in Table 5 define the well-typednames, processes and systems. The typing rules in Fig. 4can be used to decide whether a name, process or systemcan be judged as well-typed.

Rule (T-Input) states that, for typing a(x).P in an agent mwith task set j, one must ensure that: (1) a has a channel type[premise G ra:ch(ha, T)]. (2) ha is consistent with TBACpolicy [premise 8 t [ ha ((t,a) [ TPA)]. (3) If channel ais protected by TPA, then at least one task in j possessesthe access privilege on a (premise a � PS _ jt > ha = 1).(4) P is well-typed under the assumption that x has type T(premise G,x:T;j rS

mP).

Table 5 Typing judgments

G r x:T good name x of type T in G

G rSA good system A respecting G and S

G;j rmS P good process P respecting G and S when

P is in agent m with task set j


Rule (T-Exec) states that, for typing process exec t(x).P in an agent m with task set j, one must ensure that:(1) t has a task type, x has a task instance type and mhas an agent type. (2) Agent m has the privilege toexecute task t (premise t [ he). (3) P can be well-typedin agent m with task set j< {t(x)}.

Rule (T-Agent) states that, for typing m[P]j, one mustensure that: (1) Agent m has an agent type. (2) The type ofm is consistent with TBAC policy fpremise 8t [ hd((m,t) [ TDA] and 8t [ he[(m, t) [ UTA]g. (3) j isconsistent with the type of m (premise jet # he andjdt # hd). (4) P can be well-typed in agent m with j.

The explanation of rule (T-Output) is the same as rule(T-Input). The explanations of rule (T-Dist), (T-Subm)and (T-Alsubm) are the same as rule (T-Exec). The otherrules are easy to understand.

4.3 Subject reduction

The soundness of our type system can be proved by subjectreduction and type safety.

Definition 3: (Well-typed). Given a TBAC policyS ¼ (TDA, UTA, TPA) and a system A, we say that A iswell-typed in S if there exists a typing environment G suchthat G rS A.

Theorem 1: (Subject reduction). If G rS A and A ! A0,then G rS A0.

Theorem 2: (Type safe). If A is well-typed in S, thenA 7! err cannot hold.

The first theorem states that well-typedness is preservedalong reductions. The second theorem ensures that systemswith well-typeness can avoid the run-time errors inTable 4. The proofs of the theorems are on Appendix.

Example 2: By the typing rules, the task agents A1–A6 definedin Section 3.3 can be well-typed. User agent Ua and Ub also canbe well-typed. Uc cannot be well-typed, because its sub-process


IETdoi

www.ietdl.org

Figure 4 Typing rules

r p1kr3l cannot be well-typed. We cannot find a type for r p1. Ifwe define ch(fT2, T5g, MT) as the type for r-p1, it cannot satisfythe premise jet > ha = 1 of rule (T-Output) becausejet ¼ fT3g for this agent. If we define ch(fT2, T3, T5g, MT)as the type for r p1, it cannot satisfy the premise 8t [ ha

((t, a) [ TPA) of rule (T-Output) because(T3, r p1) � S1.TPA. Similarly, agent Ud cannot be well-typed, because its sub-process w p3 and exec T3(xh) cannotbe well-typed.

For the user agent that cannot be well-typed, theadministrator can adjust the system to avoid such errors bythe following ways:


1. Adjust the security policy. If the user must possess thespecified permissions to finish its job, the administratorcan adjust the TBAC policy to assign the requiredpermissions to the users. For our example, theadministrator can add the access control rule (T3,r p1) tothe TPA policy of S1. This adjustment will make agent Ucwell-typed

S01 ¼ S1 < {TPA:{(T 3, r p1)}}

2. Adjust the user’s behaviours. For our example, Udattempts to write the production schedule to w p3, which

469


47

&

www.ietdl.org

is forbidden by TPA policy of S1. Ud also attempts to accepttask T3, which is forbidden by UTA policy of S1. Thebehaviours of user Ud must be changed to safely run underthe policy S1 and S1

0

Ud ::¼ Ud[!(exec T 5(xe):r p1kr6l:r6(po):r p3kr7l:

r7(shpsch):w p5kprodschl:subm T 5(xe))]{ }

After the adjustment, the system can be well-typed in S01under the following type environment

G ¼ {T 1: tsk, ia: ins, xa: ins, A1: agt({T 1}, {}),

Ua: agt({}, {T 1, T 6}), Ub: agt({}, {T 2, T 4}),

Uc: agt({}, {T 3}), Ud : agt({}, {T 5}),

po: T , w p1: ch({T 1}, T ), r p1: ch({T 2, T 3, T 5},

ch({}, T )), ret addr: ch({}, T ), r2: ch({}, T ), r4:

ch({}, T ), r6: ch({}, T ),

prodsch: T 0, w p5: ch({}, T 0), . . . }

5 Related workSeveral workflow access control models have been proposedto protect the workflow data. Atluri’s WAM model is thefirst workflow authorisation model (WAM) [3]. In thismodel, an authorisation template is associated with eachtask to specify the static parameters of the authorisation.When the task actually starts execution, the authorisationtemplate is used to derive the actual authorisation rules.Thomas and Sandhu [4] developed the TBAC model.They used an authorisation step to indicate the executionof a task. Permissions are defined on each authorisationstep, and a user can obtain permissions from anauthorisation step. Knorr [5] considered the dynamic accesscontrol of workflow. He used Petri nets to model theworkflow and add the task dimension to the access controlmatrix. He shows that dynamic access control can be usedto eliminate unnecessary access and to enforce systemsecurity. Roles can also be introduced into the models [6, 7].

Many formal methods have been used to formalise theworkflow process and detect structural conflicts such asdeadlock, lack of synchronisation and so on. The mainformal methods include Petri nets [11], graph reduction[12] and logic-based reduction [13]. p-calculus has alsobeen applied to formalise workflow in recent years. Padgetand Bradford [14] are the first attempt to model thebusiness process by p-calculus, and more general methodshave been proposed to formalise the tasks and taskrelationships in [15] and workflow patterns in [16].

Despite the importance of workflow access control, littleeffort has been taken on modelling and analysing theworkflow systems with authorisations. To the best of ourknowledge, Petri nets is the only formal method to


formalise the workflow access control model [17]. In [17],Atluri used colour timed Petri nets (CTPN) to representthe WAM and analyse the safety of WAM. The CTPNcan be translated into Petri nets, and the analysis methodsof Petri nets can be used to analyse the correctness andsafety of WAM. However, this method can only analysethe safety properties of the workflow systems. It can hardlyanalyse the security properties of the system, since users areall represented by tokens and the behaviours of these usershave no differences. In our method, the behaviours ofdifferent users can be represented by different WFPIprocesses. Security properties of the system can be analysedbased on users’ behaviours, including authorised andunauthorised actions. This is one of the major advantagesof introducing p-calculus into the security analysis ofworkflow access control.

Types play an important role in programming languages [18]and process calculus [19]. Different types have been proposed tosatisfy the different access control models and policies: group-based access control [20], discrete access control [21, 22],mandatory access control [23] and role-based access control[24]. In these researches, the permissions of an agent aredetermined by its groups [20], its capabilities [21, 22], itssecurity level [23] or its roles [24]. To the best of ourknowledge, no previous study building on process calculi hasever been conducted on TBAC in workflow systems. Theresearches in [20–23] aim at static access control policies: anagent’s permissions are determined before the reductions anddo not change during the reductions. The most related workis [24]. In [24], the authors define a distributed calculus withprimitives to activate and deactivate roles. The agent canactivate different roles to obtain different permissions indifferent sessions by its own decisions. Since in a workflowsystem the activation and deactivation of tasks depend on theinteractions between task agents and user agents, their methodis not suitable for modelling workflow access control directly.

6 Conclusion and future workIn this paper, we have presented a method for formalisingand analysing security properties of workflow systems. AWFPI has been proposed for formalising workflowsystems. By adding task execution and submissionprimitives and tagging each agent with its executing anddistributing tasks, WFPI can flexibly represent the conceptsand elements in workflow systems. A type system has beendeveloped to ensure that the specified TBAC policy isabided by during system reductions. By subject reduction,the well-typed system can avoid access violations in runtime. To the best of our knowledge, our research is the firstattempt to study the workflow access control by processcalculus and types.

Our work can be extended in the following theoreticalaspects. First, labelled transition system (LTS) semanticscan be defined to study the security behaviours of workflow


IETdoi

www.ietdl.org

systems in open contexts. Secondly, sub-type relation onchannels and agents can be defined to enforce more strictaccess control policies. We also can define type systems toaddress the extension of TBAC models, introducing roles,seperation of duty (SOD) constraints and so on.

Because of the profound mathematical background of ourapproach, it is a formidable task for workflow engineers andadministrators to understand and utilise our approach inpractical applications. If they try to do the formalisationand type judgment manually, these steps may impose greatworkloads on them. Also, when error messages are raisedduring type analysis, it is also irksome for them to locatethe errors and make corrections if the policy set andworkflow processes are large. Therefore an analysis tool isnecessary to support administrators to utilise our approachwithout knowing the underlying operation details. For thispurpose, we have developed a type tool by Java toimplement type judgment and type inference for WFPIscripts. This tool can assist the administrators to do thetype analysis automatically. Our work will be extended inthe following implementation aspects. First, thetransformation tool should be developed to automaticallytransform the workflow processes, which may be defined inBPEL or XPDL formats, into WFPI scripts. Secondly, ifthe error messages are raised during type analysis, the errorshould be automatically located to the tasks and accesscontrol rules by the feedback tool. The tool should alsogive some advice on how to adjust the workflow processesand access control rules automatically. All this will greatlylighten the burden of administrators in practical applications.

7 AcknowledgmentsThe work is partially supported by the National NaturalScience Foundation of China (Grant no. 60673008, Grantno. 60673122), the National High-Tech Researchand Development Program of China (Grant No.2007AA04Z135) and the National Basic ResearchProgram of China (Grant No. 2002CB312006).

8 References

[1] WF-TC00-1003: ‘Workflow management coalition: theworkflow reference model’, January 1995

[2] WF-TC-1019: ‘Workflow security considerations-whitepaper’, February 1998

[3] ATLURI V., HUANG W.K.: ‘An authorization model forworkflows’. Proc. 5th European Symp. on Research inComputer Security, Rome, Italy, September 1996,pp. 44–64

[4] THOMAS R.K., SANDHU R.S.: ‘Task-based authorizationcontrols (TBAC): a family of models for active andenterprise-oriented authorization management’. Proc. IFIP


WG11.3 Workshop on Database Security, Vancouver,Canada, August 1997, pp. 166–181

[5] KNORR K.: ‘Dynamic access control through Petri networkflows’. Proc. 16th Annual Computer SecurityApplications Conf., New Orleans, December 2000,pp. 159–167

[6] WU S.L., SHETH A., MILLER J., LUO Z.W.: ‘Authorization andaccess control of application data in workflow systems’,J. Intell. Inf. Syst., 2002, 18, (1), pp. 71–94

[7] OH S., PARK S.: ‘Task role based access control models’,Inf. Syst., 2003, 28, (6), pp. 533–562

[8] OASIS: ‘Web Services Business Process ExecutionLanguage (WS-BPEL)’, Version 2.0, January 2007

[9] MILNER R., PARROW J., WALKER D.: ‘A calculus of mobileprocesses’, J. Inf. Comput., 1992, 100, (1), pp. 1–77

[10] PARROW J.: ‘An introduction to the Pi calculus,’ inBERGSTRA J.A., PONSE A., SMOLKA S.A. (EDS): ‘Handbook ofprocess algebra’ (Elsevier, 2001), pp. 479–543

[11] AALST W.M.P.V.D.: ‘The application of Petri nets toworkflow management’, J. Circuits Syst. Comput., 1998, 8,(1), pp. 21–26

[12] SADIQ W., ORLOWSKA M.E.: ‘Analyzing process models usinggraph reduction techniques’, Inf. Syst., 2000, 25, (2),pp. 117–134

[13] BI H., ZHAO J.L.: ‘Applying propositional logic to workflowverification’, Inf. Technol. Manag., 2004, 5, (3,4), pp. 293–318

[14] PADGET J.A., BRADFORD R.J.: ‘A Pi-Calculus model of aSpanish fish market – preliminary report’. 1st Int.Workshop on Agent Mediated Electronic Trading,Minneapolis, USA, May 1998, pp. 166–188

[15] DONG Y., ZHANG S.S.: ‘Approach for workflow modelingusing Pi-Calculus’, J. Zhejiang Univ. Sci., 2003, 4, (6),pp. 643–650

[16] PUHLMANN F., WESKE M.: ‘Using the Pi-Calculus forformalizing workflow patterns’. 3rd Int. Conf. BusinessProcess Management, Nancy, September 2005, pp. 153–168

[17] ATLURI V., HUANG W.K.: ‘A Petri net based safety analysis ofworkflow authorization models’, J. Comput. Secur., 2000, 8,(2, 3), pp. 1–13

[18] PIERCE B.C.: ‘Types and programming languages’ (MITPress, 2002)

[19] SANGIORGI D., WALKER D.: ‘The Pi-Calculus: a theory ofmobile processes’ (Cambridge University Press, 2001)

471


47

&

www.ietdl.org

[20] CARDELLI L., GHELLI G., GORDON A.D.: ‘Secrecy and groupcreation’. Proc. 11th Int. Conf. Concurrency Theory, PA,USA, August 2000, pp. 365–379

[21] BUGLIESI M., COLAZZO D., CRAFA S.: ‘Type based discretionaryaccess control’. Proc. 15th Int. Conf. Concurrency Theory,London, UK, September 2004, pp. 225–239

[22] HENNESSY M., RIELY J.: ‘Resource access control in systemsof mobile agents’, Inf. Comput., 2002, 173, (1), pp. 82–120

[23] HENNESSY M., RIELY J.: ‘Information flow vs. resourceaccess in the asynchronous Pi-Calculus’, ACM Trans.Program. Lang. Syst., 2002, 24, (5), pp. 566–591

[24] BRAGHIN C., GORLA D., SASSONE V.: ‘A distributed calculus forrole-based access control’, J. Comput. Secur., 2006, 14, (2),pp. 113–155

9 Appendix: proof of subjectreductionIn this appendix, we prove subject reduction theorems ofSection 4.

Lemma 3: (Weakening). If G rS A and x � fv(A), then G,x:T rS A.

Proof: The proof is by induction on the depth of theinference of type judgment for G rS A. A

Lemma 4: (Strengthening). If G, x:T rS A and x � fv(A)then G rS A.


Lemma 5: (Substitution). If G rS A and G(x) ¼ G( y), thenG r SAfy/xg.


Lemma 6: (Structural congruence). If G r S A and A ; B,then G r S B.

Proof: To prove that, we formally define a system context,as ; is closed under all such contexts. A context C[ ] is asystem with an occurrence of a ‘hole’ to be filled with anysystem A, thus yielding C[A]. Formally, C[ ] ::¼ [ ] jC[]jAj (yx)C[ ].

The lemma follows by showing that A ; B implies: (1)If G rS A, then G rS B. (2) If G rS B, then G rS A.

We proceed by induction on the derivation of A ; B. Thebasic cases cover the axioms in Table 2. We only prove rule(R-ASplit), the proof for other rules are similar.


(R-ASplit): Then, A ¼ m[exec t(i).P j Q]j and B ¼ m[exect(i).P]j j m[Q]j with ji ¼1. For (1), assume G rSm[exect(i).P j Q]j. This must have been derived from (T-Agent),with G;j rS

m exec t(i).P j Q and G rm:agt(hd, he), andfrom (T-Par), with G;j rS

m exec t(i).P and G;j rSmQ. By

(T-Agent), we have G rSm[exec t(i).P]j and G rS m[Q]j.By (T-SysPar), we have G rS m[exec t(i).P]j j m[Q]j.Hence, G rSB. The proof for part (2) is similar.

Context closure: Let A ¼ C[A0] and B ¼ C[B0] for someA0 ; B0. This case can be proved by induction on thestructure of C[ ]:

a. For the case C[ ] ¼ [ ] : we have that A ¼ [A0] ¼ A0 andB ¼ [B0] ¼ B0. For (1), assume G rS [A0]. Since [A0] ¼ A0, wehave G rSA0. By assumption A0 ;B0, we can use inductionto prove that G rSB0. Hence, G rSB. Part (2) is symmetric.

b. For the case C[ ] ¼ D[ ] j E : then A ¼ D[A0] j E andB ¼ D[B0] j E. For (1), assume G rSD[A0] j E. This musthave been derived from (T-SysPar), with G rSD[A0] andG rSE. As D[ ] is smaller than C[ ], we can use inductionto prove that G rSD[B0]. By (T-SysPar), wehave G rSD[B0] j E. Hence, G rSB. Part (2) is symmetric.

c. For the case C[ ] ¼ (yx)D[ ] : then A ¼ (yx)D[A0] andB ¼ (yx)D[B0]. For (1), assume G rS(yx)DA0. This musthave been derived from T-SysRes with G,x TrSDA0 forsome T. As D is smaller than C we can use induction toprove that G,x:T rSDB0. By T-SysPar we haveG rS

ðyxD [B])0. Hence G rSB. Part (2) is symmetric. A

Theorem 1: (Subject reduction). If G rSA and A! A0,then G rSA0.

Proof: By induction on the derivation of A! A0. The basiccases cover the axioms in Table 3.

(R-ExtCom): Then A ¼ m[akvl.P j R]j j n[a(x).Q j S]j0 andA0 ¼ m[P j R]j j n[Qfv/xgjS]j0 . Assume G rSA. This musthave been derived from (T-SysPar), withG rS

m[akvl.P j R]j and G rS n[a(x).Q j S]j0 , and from(T-Agent), with G;j rS

m akvl.PjR, G;j0 rSna(x).Q j S,

G rm:agt(hd, he) and G rn:agt(h0d, h0e).

For G;j rSm akvl.P j R, it must have been derived from (T-

Par), with G;j rSm akvl.P and G;j rS

mR, and from (T-Output), with G rv : T for some T, G ra:ch(ha, T),a � PS _ jet > ha = 1 and G;j rS

mP. By (T-Par),we have G;j rS

mP j R. By (T-Agent), G rSm m[PjR]j.

For G;j0 rSna(x).Q j S, it must have been derived from (T-

Par), with G;j0 rSna(x).Q and G;j0 rS

nS, and from (T-Input),with G ra:ch(ha, T), a � PS _ j0et > ha = 1, andG,x : T;j0 rS

nQ. Let G0 ¼ G < {x : T }. By substitutionlemma, since G

0(x) ¼ G0(v) ¼ T, we obtain G

0;j0 rSnQfv/xg.

Since all the occurrences of x in Q are substituted by v,


IETdo

www.ietdl.org

x � fv(Q), by strengthening lemma, G;j0 rSnQfv/xg. By (T-

Par), G;j0 rSnQfv/xgjS. By (T-Agent), G rSn[Qfv/xg j S]j0 .

By (T-SysPar), we can derive G rSm[P j R]j j n[Qfv/xg j S]j0 , that is, G rSA0.

(R-Exec): Then A ¼ m[exec t(i).P j R]j j n[exec t(x).Q]j0and A 0 ¼ m[P j R]j<{tkil} j n[Qfi/xg]j0<{ t(i)}. Assume G rS

A. This must have been derived from (T-SysPar), withG rSm[exec t(i).P j R]j and G rS n[exec t(x).Q]j0 .

For G rSm[exec t(i).P j R]j, it must have beenderived from (T-Agent), with G;j rS

m exec t(i).P j R,G rm:agt(hd, he), jet # he and jdt # hd and from (T-Par),with G;j rS

m exec t(i).P and G;j rSmR and from (T-Dist),

with G rt:tsk, G ri:ins, t [ hd and G;j< ftkilgrSmP. Let

j00 ¼ j< ftkilg, we have j00dt ¼ jdt < {t}, j00et ¼ jet. Sincet [ hd, we have j00dt # hd. By (T-Par) and (T-Agent), wehave G rSm[P j R]j00 that is, G rSm[P j R]j<{tkil}.

For G rSn[exec t(x).Q]j0 , it must have been derived from(T-Agent), with G;j0 rS

n exec t(x).Q, G rn:agt(h0d, h0e),j0et # h0e and j0dt # h0d and from (T-Exec), with t [ he,and G;j0< ft(x)grS

nQ. By substitution lemma, sinceG(x) ¼ G(i) ¼ ins, we obtain G;j0< ft(i)grS

nQfi/xg. Letj000

¼ j0<ft(i)g, we have j000

dt ¼ j0dt, j000

et ¼ j0et < {t}. Sincet [ he, we have j

000

et # he. By (T-Agent), we haveG rSn[Q]

j000 , that is, G rSn[Q]j0<{t(i)}.

By (T-SysPar), we can derive G rSm[P j R]j<{tkil} j n[Qfi/xg]j0<{t(i)}. Hence, G rS A0.


The proof for rule (R-IntCom) is similar to that of rule(R-ExtCom). The proof for rule (R-Subm) is similar to thatof rule (R-Exec). The proofs for other rules are simple. A

Theorem 2: (Type safe). If A is well-typed in S, then A7! err cannot hold.

Proof: We prove the contrapositive, that is, if A 7! err, thenA cannot be well-typed in S. We use induction on the depthof the inference of A! err to show all the possible cases ofrun-time errors that A can encounter.

(E-Rcv): By definition, A is m[a(x).P]j. Since A 7! err, wehave that a [ PS ^ 96 t [ jet(t, a) [ TPA. Channel a isprotected by TBAC policy and it is not defined as thepermission of tasks in jet. For any type ch(ha, T) forchannel a in any G, it must hold that jet > ha ¼1. Thus,by (T-Input), for any G, it cannot hold that G;j rS

ma(x).P.Thus, process a(x).P cannot be well-typed. Therefore byrule (T-Agent), for any G, it cannot hold thatG rSm[a(x).P]j. Therefore m[a(x).P]j cannot be well-typed.

(E-Exec): Since m[exec t(i).P]j 7! err, we have that (m,)t � UTA. Agent m cannot be the executor of task t. For anytype agt(hd, he) for agent m in any G, it must hold thatt � he. By (T-Exec), it cannot hold that G;j rS

m exec t(i).P.By (T-Agent), for any G, it cannot hold that G;j rS m[exect(i).P]. Therefore m[exec t(i).P]j cannot be well-typed.

The proof for rule (E-Snd) is similar to that of (E-Rcv). Theproofs for rule (E-Subm), rule (E-Distr) and rule (E-AlSubm) are similar to that of (E-Exec). The proofs forother rules are simple. A

473


Download - Types for task-based access control in workflow systems

Top Related