If (Reachable(p, q)⊕Reachable(q, p)) == true, and LET(p) < LET(q), Reachable(p, q) == true.
On the other hand, two processes are concurrent if and only if they are structurally parallel and overlapped in EAIs. On the basis of Lemma 5, a process is before another one if one of the following statements holds, (1) the latter is structurally reachable from the former, and (2) they are structurally parallel and the EAI of the former is before the EAI of the latter. The definition of the structural and temporal relationships in LRTS workflow is formally described as following.
Definition 10 (Structural and Temporal Relationships in LRTS workflow) For an LRTS workflow w,
Concurrent: Pw×Pw⇒{true, false}
Concurrent(p, q) == true if and only if
( Parallel(p, q)∧EAI(p)≈TIEAI(q) ) == true.
Before: Pw×Pw⇒{true, false}
Before(p, q) == true if and only if
( Reachable(p, q)∨( Parallel(p, q)∧EAI(p)pTIEAI(q) ) ) == true.
After: Pw×Pw⇒{true, false}
After(p, q) == true if and only if Before(q, p) == true.
Chapter 3. A Delegation Framework for WfMS based on Task-Role based Access Control and TS workflow
Tasks represent the basic logical steps of business processes, and roles combining users with similar responsibility together are the core components for access control management in modern WfMS. With both tasks and roles as core concept, we introduce a delegation mechanism for WfMS coordinated with TRBAC. In section 3.1, TRBAC and the issues related to delegation in WfMS are sketched. The task and role models adopted in this dissertation are described in section 3.2, and our delegation framework for WfMS and TRBAC is depicted in section 3.3. In section 3.4, a case study is made, and the related works are discussed and compared with our methodology in section 3.5.
3.1 Background
3.1.1 Task-Role based Access Control Model
Figure 10 The TRBAC Model [17]
Based on RBAC96 [15][16], TRBAC model [17] illustrated in Figure 10 works for modern enterprise environments in which tasks are the fundamental units of business processes.
TRBAC model binds permissions on tasks and groups users operating the same tasks into roles.
Rather than accessing business objects directly [15][16], users accomplish their works through tasks in which permissions are properly defined and protected. Restricting the access rights of business objects on tasks facilitates permission management and reduces the risks of inappropriate permission authority made by users. In TRBAC [17], tasks are classified into four classes according to whether the task participates in a business process and whether the task is inherited by the ancestor job. The classes of tasks in TRBAC model are illustrated in Table 1.
Table 1 Classes of Tasks in TRBAC Model [17]
Non-inheritable Inheritable
Passive access P (private) S (supervision)
Active access W (workflow) A (approval)
3.1.2 Delegation Approaches in RBAC and TRBAC
Delegation is to authorize subjects like access rights or works between users or roles, and is often built based on access control models. The user (or role) authorizing the subject is the delegator, and the one who receives it is the delegatee. In RBAC [15][16], permissions to business objects, like documents or devices, etc. are bound with roles. RBDM0 [19] provides a flexible way for granting and revoking permissions between roles. RBDM1 [20], an extension of RBDM0 [19], is more realistic since it organizes roles with hierarchy. Both techniques are focused on delegation of roles among human users through identifying can-delegation relationships between roles.
In [21], the essence of this delegation model is that a user delegates a particular right to another user, and delegation of partial permissions is allowed. Osborn separates users in organization, role hierarchies, and relationships among privileges into different graph models in [22] and [41], and shows a simple way to delegate privileges to users by creating a delegatee
role. In [18], Crampton gives a further discussion about both granting and transferring access rights between roles. When access rights are granted from the delegator to the delegatee, the delegated access rights are available for both the delegator and the delegatee [18]. On the other hand, if the access rights are transferred, only the delegatee holds the access rights after the delegation [18]. Besides, Crampton considers both can-delegate and can-receive relationships, and introduces the concept of administrative scope to improve the efficiencies in delegation controlling [18].
Besides, tasks, the basic logic units of business processes, should also be considered in delegation. In [18], Crampton addresses the issues like upward delegation and authorization of appropriate permissions for delegation to adopt RBAC-based delegation mechanism in task-based WfMS. Bammigatti associates tasks into permission management and develops a new model for using RBAC in workflow system [42]. In TAC model [43], the permissions possessed by roles and required by tasks are described separately, and the assignment of tasks to roles is thus constrained. With such constraints, a protocol enabling delegation of task instances from users to roles is established [43].
TRBAC [17] binds the permissions with tasks, and the tasks with roles. With the roles assigned to users, users access business objects and accomplish their duties through tasks.
Therefore, authorization of permissions is not necessary for delegation of tasks and task instances in TRBAC. In our previous work [24], a delegation framework for TRBAC has been initially established without considering the temporal issues. Zhang et al. develops a delegation model for time constraints-based TRBAC [44]. However, Zhang reduces TRBAC model as TRBACM model in which permissions and tasks are separately bound with roles. In [44], users delegate permissions together with tasks to accomplish their works, and the methodology violates the primary sprits of TRBAC [17].
3.1.3 Separation of Duty
Separation of Duty (SOD) is a security principle which requires multiple users to be responsible for the completion of a work [45]. Since delegation transfers permissions and tasks among users, the delegation approaches also follows the SOD policy of the corresponding access control system. In RBDM1 [16], Ferraiolo defines SOD as “For a particular set of transactions, no single individual is allowed to execute all the transactions within the set.”
Botha discusses SOD in workflow environments both statically and dynamically [46]. In Botha’s study, four possible conflicts, conflicting roles, conflicting permissions, conflicting users, and conflicting tasks, are described, and the corresponding methods for the conflicts are developed.
TRBAC [17] offers SOD policy at both task and instance level, and defines that some tasks are mutually-exclusive to each other. In task level SOD, for the roles played by a user, none of the tasks assigned to the roles are mutually-exclusive. In instance level SOD, the policy is effective for the tasks belonging to the same workflow instance. The task instances instantiated from the mutually-exclusive tasks in a workflow instance can not be executed by the same user [17]. In this dissertation, we follow the SOD policy established in TRBAC when delegation.
3.2 Task and Role Model
Tasks are the basic components describing pieces of works in logical steps within a workflow [1], and are modeled as activity processes in TS workflow model. Permissions are the rules describing the admission in accessing business objects such as documents or computation resources. In this dissertation, individual permissions are bound with tasks on the basis of TRBAC. Besides, it is assumed that only the tasks related to enactment of workflows can be delegated during run-time, and therefore, only “Workflow” and “Approval” are considered as the classes of tasks in this dissertation. Task is formally defined as following.