A user set C
The delegated task t Output:
A delegatee user set D without the user assignment loop problem AALTm
01 Begin
02 D = C – t.d_role.r_task 03 End
Algorithm 4.2 Tracing method algorithm for user assignment loop problem The difference between the two methods is where to log the information of delegator users. The marking method records the information of delegator users in the user attribute, but the tracing method uses the delegatee role to store the information of delegator users. Generally speaking, the tracing method is faster than marking method in checking user assignment loop for one delegated task. This is because that tracing method only verifies users in the delegator user table. But marking method has to go through all the users in the delegatee user set to check whether the delegated task ID is in their d_tasks attributes. Normally, delegator users in multi-delegations are not more than five people, but the numbers of users in delegatee user set are. Thus, executing tracing method is usually faster than marking
method in checking loop problem for one task.
The advantage of marking method is that it is easy to know what tasks are delegated by users. The marking method is better used before the selection algorithm to help the system to collect delegatee user set. When picking up delegatee users, the engine checks the d_tasks in users. If the delegated task ID is appeared in this attribute, this user is not chosen into delegatee user set. The tracing method can also be used before executing selection algorithm. But in comparison of executing time, the marking method is faster then tracing. The reason is that tracing method traces delegator user table every time before a user is picked. The marking method only has to compare the delegated ID with the d_tasks attribute. Normally, the size of d_tasks attribute is smaller than the delegator user table. Thus, the marking method is better than the tracing method to put at the beginning of selection algorithm.
4.2. Separation of Duty (SoD)
The separation of duty (SoD) is a security principle. When two or more tasks in the same process are performed by one user, SoD problem might occur.
Fig.4.2 A loan request process
Fig.4.3 presents a loan process. All the tasks are assigned to different users through different roles. Suppose that T2 is assigned to User2 through a process role named account manager. T3 is assigned to User3 through another process role named department manager. Now User3 is unexpectedly unavailable, and the task approval task is needed to be executed. If T3 is automatically delegated by the
engine and is assigned to User2, thus, User2 can easily approve any amount of loans.
To state the SoD principle in detail, tasks are divided into two types: decision task and general task. The definition is described below.
Definition 4.1 (Decision Task): A task within the workflow where a single thread of control makes a decision upon which branch to take when encountered with at least one alternative workflow branches. This kind of task is called decision task.
In definition 4.1, decision tasks decide the execution path of a process. Using Fig 3.5 as an example, T2 and T3 are loan approval tasks. If managers in T2 or T3 disagree with loan requests, these loan requests are dropped. Obviously, T2 and T3 can effect the execution of process. Therefore, T2 and T3 are decision tasks. Check points and decision making tasks in processes are usually classed as decision tasks.
From workflow viewpoint, XOR-split nodes are classed as decision tasks. T1 and T5 in Fig.4.3 are general tasks. These kinds of tasks are routines or those that never change process execution path.
Definition 4.2 (General Task): All Tasks which are not classed as decision tasks are general tasks.
When constructing the delegatee user set, the workflow engine shall check the picked users’ SoD constraints. If some ones violate these constraints, they cannot be selected into delegatee user set. There are two types of separation of duty constraints:
strong SoD and weak SoD.
Definition 4.3 (Strong SoD): Any two tasks in one process, including decision tasks and general tasks, are not performed by the same person is called Strong Separation of Duty.
That the delegations both decision and general tasks cannot violate separation of duty constraints is called strong SoD. Limiting decision tasks not to violate separation of duty constraints only is called weak SoD. The benefit of strong SoD constraint is to prevent that a task in highly secure processes, such as military processes, are performed by the same user. Usually, the enterprise processes only require weak SoD constraints.
Definition 4.4 (Weak SoD): That the decision tasks in one process only are restricted to be performed by different users is called Weak Separation of Duty.
4.2.1. Analysis method of Weak SoD
The weak SoD principle does not allow two decision tasks to be executed by one person, since one can easily change the execution path or result when holding two or more decision tasks in a process. Algorithm 4.3 gives a method filtering the candidate user set to assure that the delegatee user set violates no weak SoD principle.
Algorithm 4.3 (Analysis of Weak SoD Principle)