types for task-based access control in workflow systems

Download Types for task-based access control in workflow systems

Post on 19-Sep-2016

213 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • c, Patio

    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,

    IETdoi

    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.

    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.

    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.

    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

    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

    Abstract: Task-based access control (TBAC) is a exible seSoftw., 2008, Vol. 2, No. 5, pp. 461473: 10.1049/iet-sen:20070098ISSN 1751-8806

    ess control in

    eoples Republic of Chinan, School of Software, Tsinghua University, Beijing 100084,

    rity mechanism, which has been widely implemented in461

    & The Institution of Engineering and Technology 2008

  • sequential, and-split, and-join, or-split, or-join, choice,

    ator can also verifye denitions in this

    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

    rol

    portant mechanismsdenes which userser can access theodel for WfMSs.

    46

    &

    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.

    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

    Figure 1 Framework of WFMS2The Institution of Engineering and Technology 2008Denition 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 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.

    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 Workow

    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

    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.

    2.2 Task-based access cont

    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

  • permissions related to that task any longer. TBAC is a

    schedule and thelso arranged. When, invoice processinghe customer.

    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

    this example can bedened as follows

    IETdo

    www.ietdl.orgexible and dynamic access control mechanism: the userspermissions can change dynamically by its status during theexecution of workow 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 dene the security policy in WfMSs.

    Denition 2: ATBAC policy for a workow system can bedened 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)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

    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)},

    UTA:{(Ua, T1), (Ua, T6), (Ub, T2), (Ub, T4),

    (Uc, T3), (Ud , T5)},

    TPA:{(T1, w p1), (T2, r p1), (T2, w p2), (T3, r p2),

    (T3, w p4), (T4, r p2), (T4, w p3), (T5, r p1),

    (T5, r p3), (T6, r p4)})

    2.3 Motivation

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

    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.

    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 the

    price. Meanwhile, the shipmentproduction schedule for the order are athese concurrent paths are completedcan proceed and the invoice is sent to t

    Fig. 2 also illustrates the users and perm

Recommended

View more >