Types for task-based access control in workflow systems

Download Types for task-based access control in workflow systems

Post on 19-Sep-2016




0 download


<ul><li><p>c, Patio</p><p>cuworkow 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 workow systems under TBAC policy. To achieve this goal, the authors rst present WFPI,</p><p>IETdoi</p><p>www.ietdl.orgworkow p-calculus. By adding task execution and submission primitives, and tagging each agent with itsexecuting and distributing tasks, WFPI can exibly represent the concepts and elements in workow systems.Then, based on WFPI, a type system is proposed to ensure that the well-typed workow systems can abide bythe TBAC policy at run time, by avoiding run-time access violations. To the best of ones knowledge, the presentresearch is the rst attempt to study workow access control by process calculus and types.</p><p>1 IntroductionWorkow 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 workow consists of a set of tasks, andtheir order of invocation and information ow, according tocontrol ow dependencies. In the workow system, the taskshould be carried out by a legitimate user with authorisedactions according to the workow security policies. Accesscontrol is an important security mechanism to ensure datasecurity in workow management systems (WfMSs) [2].Several workow access control models have been proposed toprotect data and resources in WfMSs [37]. 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 exible and dynamic access controlmechanism: the users permissions can change dynamically byits status during the execution of the workow processes.</p><p>Despite the importance of workow access control, littleeffort has been taken on analysing the security properties ofworkow systems, because of the lack of appropriate formalmethods. In this paper, we aim at developing such amethod to analyse whether there exist unauthorisedaccesses in workow systems before the running ofworkow processes. To achieve this goal, we rst presentWFPI, workow 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 workow systems can be formalised by agents.Secondly, we add task execution primitives (exec and exec)and task submission primitives (subm and subm) to denotethe specic concepts in workow systems. The task set jcan be changed by these primitives according to reductionrules. By these extensions, WFPI can exibly represent theconcepts and elements in workow systems.</p><p>To analyse the security properties of the workow system,we propose a type system to ensure that the specied TBACpolicy can be abided by. By subject reduction, the well-typedPublished in IET SoftwareReceived on 4th August 2007Revised on 6th March 2008doi: 10.1049/iet-sen:20070098</p><p>Types for task-based acworkow systemsY. Lu1 L. Zhang2 J. Sun21College of Software, Shenzhen University, Shenzhen 5180602Key Laboratory for Information Security of Ministry of EducPeoples Republic of ChinaE-mail: luyahui@szu.edu.cn</p><p>Abstract: Task-based access control (TBAC) is a exible seSoftw., 2008, Vol. 2, No. 5, pp. 461473: 10.1049/iet-sen:20070098ISSN 1751-8806</p><p>ess control in</p><p>eoples Republic of Chinan, School of Software, Tsinghua University, Beijing 100084,</p><p>rity mechanism, which has been widely implemented in461</p><p>&amp; The Institution of Engineering and Technology 2008</p></li><li><p>sequential, and-split, and-join, or-split, or-join, choice,</p><p>ator can also verifye denitions in this</p><p>process can bences. Each instancethe workow. TasksTask instances arecies between them.d from the possibleresented by this taskworkow data andls to nish its task.ta and resources aretrol policies in the</p><p>rol</p><p>portant mechanismsdenes which userser can access theodel for WfMSs.</p><p>46</p><p>&amp;</p><p>www.ietdl.orgparallel 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 byworkow tasks by accessing resources. The relationshipsbetween users, tasks and resources can be dened by accesscontrol rules.</p><p>As Fig. 1 shows, a workow may be characterised as twostages in WfMSs: the build time and the run time. Inbuild time, the system administrator denes workowprocesses and access control rules (or policies), in textual or</p><p>Figure 1 Framework of WFMS2The Institution of Engineering and Technology 2008Denition 1: The TBAC model is composed of thefollowing components:</p><p>US: the set of users. A user may be human, machine agent,role or web service.</p><p>TS: the set of tasks.</p><p>TD: the set of task distributors.</p><p>RS: the set of resources (or objects). The set of operations onthe resources is dened as OP.system can abide by the specied TBAC policy at run time,by avoiding two kinds of run-time access violations: the usersattempt to execute the tasks without proper authorisations andto access resources without corresponding permissions.</p><p>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.</p><p>2 Background and motivation2.1 Workow</p><p>Workow 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]. Workow process denes thedependencies between tasks. The dependencies can be</p><p>graphical form. The system administrthe correctness and consistence of thesstage. In run time, each workowinstantiated to several workow instarepresents a separate execution case ofare also instantiated to task instances.scheduled according to the dependenFor each task instance, a user is selectetask executors to perform the work repinstance. The user may access theresources by means of application tooWhether the user can access these dadecided by the predened access conaccess check module.</p><p>2.2 Task-based access cont</p><p>Authorisation and access control are imto ensure data security in WfMSs. Itcan execute the tasks and which uresources. We dene a general TBAC mIET Softw., 2008, Vol. 2, No. 5, pp. 461473doi: 10.1049/iet-sen:20070098</p></li><li><p>permissions related to that task any longer. TBAC is a</p><p>schedule and thelso arranged. When, invoice processinghe customer.</p><p>ssions related to eachem. User Ua, whoce, can execute taskinvoice service, canwho provides the3. User Ud, whoice, can execute taskystem: p1 (purchase(shipping schedule)ned as reading or</p><p>this example can bedened as follows</p><p>IETdo</p><p>www.ietdl.orgexible and dynamic access control mechanism: the userspermissions can change dynamically by its status during theexecution of workow processes.</p><p>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 dene the security policy in WfMSs.</p><p>Denition 2: ATBAC policy for a workow system can bedened as tuple (TDA, UTA, TPA) according to the TBACmodel.</p><p>Example 2: Fig. 2 illustrates a purchase order process which isdescribed by business process execution language (BPEL)specication in [8]. It includes six tasks. After receiving thepurchase order from a customer, the process will select ashipper for the product. Then, the nal price for the orderis calculated by adding the product price and the shipping</p><p>Figure 2 Purchase order processSoftw., 2008, Vol. 2, No. 5, pp. 461473i: 10.1049/iet-sen:20070098S1 :: (TDA:{(A1, T1), (A2, T2), (A3, T3), (A4, T4),(A5, T5), (A6, T6)},</p><p>UTA:{(Ua, T1), (Ua, T6), (Ub, T2), (Ub, T4),</p><p>(Uc, T3), (Ud , T5)},</p><p>TPA:{(T1, w p1), (T2, r p1), (T2, w p2), (T3, r p2),</p><p>(T3, w p4), (T4, r p2), (T4, w p3), (T5, r p1),</p><p>(T5, r p3), (T6, r p4)})</p><p>2.3 Motivation</p><p>During the running of process instances in the workowsystem, there may exist two kinds of access violations ofTBAC policy:</p><p>1. Unauthorised execution of tasks. The user attempts toexecute tasks without proper authorisations.PS: the set of permissions. PS # 2RSOP. Permissions areprivileges to access the resources. They are dened as theoperations on the resources in RS.</p><p>TDA (task distribution assignment): TDA # TD TS.(di, tj)[ TDA denotes that di can distribute the task tj tousers for execution.</p><p>UTA (user task assignment): UTA# US TS.(ui, tj)[ UTA denotes that ui can execute task tj.</p><p>TPA (task permission assignment): TPA# TS PS.(ti, pj)[ TPA denotes that task ti has permission pj.</p><p>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 the</p><p>price. Meanwhile, the shipmentproduction schedule for the order are athese concurrent paths are completedcan proceed and the invoice is sent to t</p><p>Fig. 2 also illustrates the users and permitask. There are four users in the systprovides the customer interaction serviT1 and T6. User Ub, who provides theexecute task T2 and T4. User Uc,shipping service, can execute task Tprovides the production scheduling servT5. There are four resources in the sorder), p2 (shipping information), p3and p4 (invoice). Permissions are dewriting on these resources.</p><p>Formally, the TBAC policy S1 for463</p><p>&amp; The Institution of Engineering and Technology 2008</p></li><li><p>2. The access check procedure can be time consuming and</p><p>is analysed and ensuredand executed. By this,</p><p>.</p><p>ution. It includes vee: process denition,analysis and feedback.or denes workowuirements and denesng to the securitythe administrator canorkow process andllowing steps:</p><p>ents in the workownd relationships. Thented by the formal</p><p>: including processes,</p><p>46</p><p>&amp;</p><p>www.ietdl.orgmay inuence the performance of workow systems,especially in large systems with hundreds of users andthousands of resources.</p><p>Thus, it is meaningful if we can provide some analysis methodsand tools to check these access violations before the running of</p><p>Figure 3 Framework of security analysis by typing systems4The Institution of Engineering and Technology 2008 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 workow system, including legalbehaviours and illegal behaviours.2. Unauthorised access of resources. The user attempts toaccess resources without corresponding permissions.</p><p>The above access violations can be prevented in run time by aworkow engine and an access check module. During therunning of each process instance, only the workow 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.</p><p>Although these violations can be checked and excluded bythe workow engine and the access check module during therunning of process instances, there exist some disadvantagesfor these run-timemechanisms to prevent the access violations:</p><p>1. Some users require specic resources to complete theirtasks. If the access control policy is not congured correctlyand the system rejects these specic access requests, theseusers cannot nish their jobs successfully. This may result infailures, exceptions or deadlocks for these process instances.</p><p>process instances. Only after the systemas secure, the process can be instantiatedthe disadvantages above can be avoided</p><p>2.4 Our solution</p><p>Fig. 3 shows the roadmap of our solparts in the build and analysis timpolicy denition, formalisation, typeIn the build time, the administratprocess according to the business reqthe access control policy accordirequirements. In the analysis time,check the consistency between the waccess control policy. It includes the fo</p><p>1. Formalisation: Formalise the elemsystem, including their behaviours afollowing elements must be represemethod:</p><p> Elements in the workow processtasks and task relationships.IET Softw., 2008, Vol. 2, No. 5, pp. 461473doi: 10.1049/iet-sen:20070098</p></li><li><p>IETdo</p><p>www.ietdl.org2. Type analysis: Utilise typing rules to check whether theuser violates the TBAC policy in the workow system. Ifthe system cannot be well-typed, there may existinconsistencies in the workow system. The administratorcan obtain the feedback information about theseinconsistencies. Then, the administrator can adjust theaccess control rules or workow process to resolve theinconsistencies. After the adjustment, the system should beanalysed again.</p><p>If the system can be well-typed in the analysis time, we canensure that the workow system will always abide by theTBAC policy during run time. Then the workow processcan be instantiated by the workow engine and executed bythe users in run time.</p><p>3 Calculus of WFPI3.1 Syntax</p><p>The syntax of WFPI calculus is given in Table 1. Thecalculus is an extension of p-calculus [9, 10]. It includesthe denition of the following terms: names, processes,agents and systems.</p><p>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.</p><p>As in p-calculus, processes can be dened as inactiveprocess, parallel composition, replication, name restriction,input prex, output prex and match prex. We add fourworkow primitives to describe the specic concepts inworkow 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.</p><p>A system consists of parallel composition agents that canshare private channels, using the operator j and n.</p><p>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 ta...</p></li></ul>


View more >