the revoker u
Pre-Condition: rsub∈T∪I, u∈U RA {
01: if (rsub∈T &&∃ap∈FDT that ap.dr=u, and ap.sub=rsub) 02: remove ap from FDT;
03: else if (rsub∈I && rsub.dr == d that u∈d.HDRL, and rsub.s≠Completed) { 04: alert dti.eu that d is going to be revoked;
05: remove rsub from rsub.eu.WL;
06: add rsub to u.WL;
07: rsub.eu = u;
08: if( u == d.dr) { 09: remove d from D 10: rsub.dr = Ø;
11: } else { 12: d.de = u;
13: u and all the users behind u in the d.HDRL are removed from d.HDRL;
14: }
15: alert dti.eu dti is transferred back to his work list;
16: } else EXCEPTION(INVALID_REVOCATION);
}
Algorithm 8 takes the subject being revoked and the revoker as the input parameters. If the subject is a task, Algorithm 8 checks whether there is any corresponding authorization form, and removes the form from FDT at line 1 and 2. Otherwise, if the subject is a task instance, Algorithm 8 checks the corresponding delegation record to assure the revocation is valid at line 3. If valid, the current delegatee of the delegated instance is first alerted at line 4. The delegated instance is removed from the delegatee’s work list, and transferred to the revoker from line 5 to 7. If the revoker is the original delegator of the delegation, the delegation record is eliminated from line 8 to 10. Otherwise, the record is updated. The delegatee is assigned to the revoker at line 9; the revoker and the delegators behind him are removed from the historical delegator list at line 10. The revoker is alerted at line 15. At line 16, an exception is raised if the revocation is invalid.
3.4 Case Study
Figure 12 (a) The Sample TS Workflow Specification, (b) The Sample Role Hierarchy and User Assignment, and (c) The Information about Tasks, Mutually-exclusive Tasks, and Authorization Applications
In this section, we adopt a specification review process as an example to show the feasibility of our approach. The workflow specification of the review process, the partial role hierarchy, and the other related information are illustrated in Figure 12. In this case, the review process is composed of two tasks, primary review and secondary review. Chief Engineer is in charge of the primary review, and Senior Engineer is responsible for the secondary one. These two review tasks are mutually-exclusive. Their EAI are both [0, 5] after calculation. Since these two tasks reside on different branches split from the AND-split process, as1, they are concurrent during execution.
Let Alex is busy in his duty, and apply for delegation of all the reviews allocated to him during the time interval [ca, cb]. The application is approved by Bob, the designated delegatee, and his supervisor. In other words, all the review jobs allocated to Alex during [ca, cb] would be delegated to Bob instead. At time c1, ca < c1 and c1+5 < cb, a workflow instance of w1, wi1 = ({i_t1, i_t2}, w1, c1), is instantiated so that the task instances i_t1 and i_t2 are instantiated on the basis of t1 and t2. i_t1 and i_t2 are offered to Chief Engineer and Senior Engineer, and allocated
to Alex and Carrie correspondingly. Now, i_t1 = (wi1, t1, r1, Allocated, u1, [c1, c1+5], Ø), and i_t1
= (wi1, t2, r2, Allocated, u3, [c1, c1+5], Ø). Because Alex has been approved to delegate all the reviews during [ca, cb] to Bob, Algorithm 7 invokes Algorithm 1 to delegate i_t1 to Bob. The delegation record d = (i1, u1, u2, [c1, c1+5], {u1}) is created, and i_t1 becomes (wi1, t1, r1, Allocated, u2, [c1, c1+5], d) after the delegation.
At time c2 which is in the middle of the active interval of i_t1, c1 < c2 < c1+5, Bob gets an emergent call and becomes unavailable right away. The task instances in his work list are all suspended. Let us assume that EER equals to 1. Thus, WfMS invokes Algorithm 6 to delegate i_t1 to another appropriate delegatee immediately. In Algorithm 6, Algorithm 5 is first invoked to explore the role hierarchy for a proper delegatee. Because t1 is typed “Workflow”, the role hierarchy is explored downward from Chief Engineer, the role i_t1 offered. Alex is the only user now playing Chief Engineer, and is eliminated from the candidate delegatee set by Algorithm 2 to avoid delegation loop. When considering Senior Engineer, Carrie is eliminated from the candidate set by Algorithm 3 because of the SOD policy, and Bob is eliminated from the candidate set by Algorithm 4 because he is unavailable. No users playing Senior Engineer are appropriate to take the task. Therefore, Engineer is then considered. After all, Deff and Elly are included in the candidate set, and Deff is randomly decided as the new delegatee of i_t1. Algorithm 1 is invoked to delegate i_t1 to Deff. d is updated as (i1, u1, u4, [c2, c1+5], {u1, u2}), and i_t1 is updated as (wi1, t1, r1, Allocated, u4, [c1, c1+5], d).
At c3, c2 < c3 <c1+5, Alex finishes his jobs ahead of time, and decides to finish i_t1 himself.
Alex invokes Algorithm 8 to revoke i_t1. Deff is first alerted and i_t1 is then revoked. The delegation record d is removed, and i_t1 is updated as (wi1, t1, r1, Allocated, u1, [c1, c1+5], Ø). In summary, this case demonstrates the delegations requested from a user and the system, and indicates how the constraints like delegation loop and SOD work in automatic delegatee decision.
3.5 Discussion
In this section, we compare our framework with the latest popular approaches: [20], [18], [43], and [44]. Table 2 illustrates the characteristics of above approaches and ours correspondingly.
Table 2 Comparison of Characteristics of Various Delegation Models
Characteristics RBDM1 [20] Crampton[18] Gaaloul [43] VTTRDM [44] Our Approach Access Control RBAC [15][16] RBAC
[15][16] TAC [43] TRBACM [44] TRBAC [17]
Delegation of
Permissions Grant Grant &
Transfer No Grant No
Delegation of
Tasks No No Transfer Yes Transfer
Delegation of Task
Instances No No No No Transfer
Time Constraints No No No Yes Yes
Automatic
Delegation No No No No Yes
RBDM1 [20] is a classic delegation model for RBAC [15][16], and can be adopted in managing delegation of permissions between users. Crampton et al. develop another RBAC-based delegation model for workflow systems [18]. Crampton's approach allows both grant and transfer operations for delegation of permissions while RBDM1 adopts only grant operation [18]. Crampton also raises the issues like upward delegation and permission authorization for delegation of tasks in work-list based workflow systems [18]. However, both RBDM1 and Crampton's approach describe no methods about delegation of tasks.
With various access control models based on tasks and roles, Gaaloul's methodology [43], VTTRDM [44], and our approach can be adopted in managing delegation of tasks for workflow systems. Gaaloul's methodology describes constraints for delegation of tasks based on Task-oriented Access Control (TAC) model [43]. TAC model describes the permissions which a role owns and a task needs. Gaaloul's methodology allows a user to delegate his tasks to a role
which has sufficient permissions to execute the tasks. Since Gaaloul's methodology allows no delegation of permissions, it is limited and inflexible when selecting the delegatee for a delegation.
In VTTRDM [44], both permissions and tasks can be delegated between users. RBDM1 [20] is adopted in VTTRDM to manage the delegation of permissions. When delegating a task, if the delegatee does not have sufficient permissions to execute the task, permission delegation from the delegator to the delegatee is necessary to enable the execution [44]. Since in VTTRDM, the delegated permission is not limited being used for the delegated tasks only, security risk exists.
In our approach, tasks are delegated through user's authorization. Our approach is based on TRBAC, and a task is executed with a set of associate permissions. Therefore, the delegatee can execute the delegated task without delegation of permissions, and the security risks brought by delegation of tasks are eliminated. Besides, in [50], delegation is defined as "A user allocates a task instance previously allocated to him to another user." While delegation of task instances is ignored in [43], and [44], our approach clearly states how to delegate task instances between users. For delegation of task instances, our methods could gather candidate delegatees and remove inappropriate users from the candidates. With our approach, a workflow system can automatically delegate an emergent task instance to an appropriate user to prevent the task instance from failure.
Regarding temporal issues, in VTTRDM, delegation is effective during a single time interval, and the delegated tasks are revoked after the interval [44]. Our approach is based on the time constraints between the delegated task instances and the related roles. Because a role might be activated in multiple time intervals, multiple or periodical time intervals are considered in our approach to provide a more realistic temporal constraints.
Chapter 4. Detecting Artifact Anomalies in TS workflow
A well-structured workflow may more possibly fail or produce unanticipated run-time behavior because of abnormal data manipulation [26][27][28][29][51]. The anomalies might be yielded differently when the temporal issues are considered. Thus, it is worthwhile to study how to detect artifact anomalies in TS workflow. In this chapter, artifact anomalies in TS workflow is first stated and modeled in section 4.1. The methodology detecting artifact anomalies in TS workflow is described in section 4.2. A case study is then introduced in section 4.3 to illustrate the feasibility of our methodology. Finally, in section 4.4, the related works are discussed and compared with our methodology.
4.1 Artifact Anomalies in TS workflow
4.1.1 Artifact Operations
In this dissertation, we assume that an activity process in a TS workflow may operate an artifact as one of the following ways: define (Def), use (Use) and kill (Kill). Defining an artifact is to assign a value to the artifact, and when an artifact is first defined, it is initialized. An activity process references an artifact through using it, and an artifact can not be used without definition. Killing an artifact is to remove the definition of the artifact, and using a killed artifact before it is defined again leads to errors during execution. As for the control processes in a TS workflow, it is assumed that they all do no operation (Nop) on any artifacts.
An artifact in a TS workflow is initially stated undefined (UD), and turns to defined&no-use (DN) after it is defined. When a DN artifact is used, its state becomes defined&referenced (DR). A DR artifact remains DR after being used, and transits to DN after
being defined again. An artifact in any states becomes UD after being killed.
On the other hand, the artifact operations made by concurrent processes are executed with undetermined order and might generate ambiguity to artifacts. When several concurrent processes operate on the same artifact, they race against each other for accessing the artifact and anomalies might thus be generated. For example, let one process make a definition to an artifact, and another one kills the artifact concurrently. The existence of the definition of the artifact becomes ambiguous because the execution order between the kill and the definition is not determined during design-time. These operations, called Racing Operations, require additional consideration during analysis, and are categorized according to the operations involved as following:
(1) Racing Definition(s)&Kill(s), abbreviated as RDK, represents a racing operation composed of both definition(s) and kill(s) with none or any usage(s).
(2) Racing Definitions, abbreviated as RDS, represents a racing operation composed of multiple definitions and no kills with none or any usage(s).
(3) Racing Kills, abbreviated as RKS, represents a racing operation composed of no definitions and multiple kills with none or any usage(s).
(4) Racing Definition&Usage(s), abbreviated as RDU, represents a racing operation composed of a single definition, any usage(s) and no kills.
(5) Racing Usage(s)&Kill, abbreviated as RUK, represents a racing operation composed of no definitions, any usage(s), and a single kill.
(6) Racing Usages, abbreviated as RUS, represents a racing operation composed of multiple usages only.
As the example mentioned above, an RDK or an RDS introduces state ambiguous (AB) to the artifact. Besides, an artifact transits to state UD after an RKS or an RUK, and state DR after an RDU. Since the artifact state after a usage varies based on the input state of the artifact, the artifact state after an RUS requires additional consideration in merging the input states of the usages involved in the RUS. The artifact and its related operations are modeled in Definition 22, and Figure 13 illustrates how artifact transits its state with different artifact operations.
Definition 22 (Artifact Model in TS workflow) For an LRTS workflow w,
The set of all the artifacts operated in w is notated as Aw.
∀a∈Aw, a.state∈{UD, DN, DR, AB}.
The artifact operation made by processes in w is described as a relationship AOP:
AOP: {p | p∈Pw, p.type == ACT}×Aw⇒{Nop, Def, Use, Kill}
{p | p∈Pw, p.type ≠ ACT}×Aw⇒{Nop}
Figure 13 The Artifact State Transit Diagram
4.1.2 Artifact Anomalies
Artifact anomalies are generated from various structural and temporal relationships between artifact operations, and can be classified into four classes: Useless Definition, Undefined Usage, Null Kill, and Ambiguous Usage:
(1) Useless Definition:
Killing or defining a DN artifact makes the previous definition useless because the definition is destroyed (or redefined) without any usage. If an artifact remains DN at the end process, its definition is also useless because it is not used before the end of the workflow. A useless definition is a kind of redundancy indicating there might be logic error in the workflow schema and should be warned to designers.
(2) Undefined Usage:
An activity process might not be correctly executed if the essential artifact is not properly defined. Therefore, an undefined usage, i.e. using an UD artifact, is an error leading to faulty execution, and is necessary to be handled by the workflow designers.
(3) Null Kill:
A null kill represents a process try to remove an inexistent definition; e.g. to kill a UD artifact. A null kill is a kind of redundancy, and designers should be noticed about it.
(4) Ambiguous Usage:
An ambiguous usage means that an activity process uses an artifact which is ambiguous in definitions or in states. Therefore, the direct usage of an AB artifact is an ambiguous usage. The usage(s) involved in an RDS, an RDK, or an RDU are also ambiguous usages. Besides, if an artifact is stated DR/DN before an RKU, the usage(s) involved in the RKU is also ambiguous.
Similarly, when an UD artifact meets an RDU, the definition in the RDU may not be made in time for the usages, and the usage(s) involved in the RDU is also ambiguous.
4.2 The Methodology Detecting Artifact Anomalies in LRTS workflow
In this section, the methodology detecting artifact anomalies in TS workflow is introduced.
To simplify our discussion, the structured loops in all the TS workflows under analysis are first reduced with the methodology introduced in section 2.4.1, and the anomaly detection is made for LRTS workflows.
Our methodology is divided into three parts. In section 4.2.1, we first describe how to traverse an LRTS workflow to collect the structural and temporal relationships between the processes and the artifact operations. In section 4.2.2, according to the structural and temporal relationships gathered in the first part, the methodology analyzing relationships between the artifact operations are described. Finally, on the basis of the analysis made in the second part, the methodology detecting artifact anomalies in an LRTS workflow is concluded in section 4.2.3
4.2.1 Gathering Structural, Temporal, Artifact Information in LRTS workflow
In this section, we describe an algorithm to traverse an LRTS workflow to collect the ABStacks, EAIs, and the artifact operations made by activity processes in the LRTS workflow.
The EAIs and ABStacks are calculated with the methods illustrated in Figure 6 and Figure 9 correspondingly. For each artifact a, an artifact operation list, notated as AOPLa, is established.
The definition of the list is formally described as following:
Definition 23 (Artifact Operation List) For an LRTS workflow w and ∀a∈Aw,
AOPLa is the list of artifact operations working on a,
∀op∈AOPLa, op = (p, a, est, let, type), p∈Pw, p.type∈{ACT, END},
est = EST(p), and let = LET(p), and type = AOP(p, a).
With the definition, the algorithm gathering structural, temporal, artifact information in
LRTS workflow is described as following:
In Algorithm 9, a traverse queue is introduced to hold the order of traversal of processes in an LRTS workflow. Starting from the start process, the processes in a TS workflow is traversed along with flows. The EAIs, ABStacks, and artifact operations lists are calculated and collected correspondingly. To prevent unnecessary redundancy, a Boolean flag mark is given to each process. Besides the start process, the mark of each process in w is initialized as false, and when a process is calculated, its mark turned to true. Since a join process may have several in-flows, a Boolean expression is checked at line 6 to assure that the join process is calculated only when