3. A Delegation Framework Based on Task-Role-Based Access Control Model
3.3. Revocation
With the temporal role in the delegation process, the revocation process only
requires only three steps. First, the engine deletes the role assignment between the delegatee role and the delegatee user. Second, task assignment between the delegated task and delegatee role is deleted. The temporal role is deleted at the last step, and the delegated task can be revoked back to the original user. For example, in Fig.3.1 the workflow engine first deletes the role assignment between the temporal delegatee role and User2. Then, it deletes the assignment between Task1 and temporal delegatee role. Last, the temporal delegatee role is delegated, and the revocation process is finished.
However, there is a problem in revocation: the delegated task is asked to be revoked while a delegatee user is performing it. Here presents a solution. According to the state of the delegated task, the result of the submitted state task is remained. And the result of the task in running state is discarded. The ready state task is revoked immediately after the revocation request is sent. The advantage of this solution is that the workflow engine doesn’t have to halt the delegatee user while he/she is performing the delegated task. Instead, it only has to re-assign the task to delegator and re-sends the information before delegating to him.
3.4. Some discussions of the task-based delegation framework
There are some discussions in our framework. Section 3.4.1 describes the benefit of using two kinds of role repositories. The advantages of using a temporal delegatee role are mentioned in Section 3.4.2.
3.4.1. Process role repository and organization role repository
The primary reason to separate the roles into two types is to clearly distinguish roles in the processes and organization. When a new project is started, new processes are created for this new project. Some roles, such as project managers,
quality assurance engineers, and programmers…etc., are created for this project only.
If using the organization role as the performers in the processes, the relationships between the new project-oriented roles and the existing organization roles must be defined. Moreover, these project-oriented roles and the relationships must be deleted after finishing the project. In this scenario, the system administrators may have to rapidly define and delete the relationships between project roles and organization roles when new projects are created and finished. It costs some maintenance efforts for the administrators.
Separating roles into the process and organization roles makes the administrators maintain these project-oriented roles easier. When each new process is created in a new project, a process role repository is allocated to this process. The administrators focus on managing the relationships of the new created roles in the process role repository. He doesn’t have to define the relationship between the new roles and the organization roles. It saves some efforts to manage the roles in the processes and organization.
3.4.2. The advantages of the temporal delegatee role
The other distinguished feature of our framework is that using a temporal delegatee role instead of directly delegating the delegator user’s role to the replaced person. The work can decrease some administrator’s maintenance efforts too.
In our framework, users perform tasks through the process roles. A process role may be assigned multiple tasks. If delegating the delegator role to the delegatee user directly, the delegatee user can perform all the tasks assigned to the delegator role.
Therefore, in other approaches without the temporal delegatee roles, the administrators have to define extra delegation constraints between the delegator role and all the tasks belonging to the delegator roles. In our framework, the
administrator manages the assignment between the delegated task and the temporal delegatee role. He/she doesn’t have to define the extra delegation constraints between the delegator role and all the tasks belonging to the delegator role. In comparison to previous approaches in managing the delegations, our framework saves some management efforts of defining the extra delegation constraints.
4. Analysis Methods for Task-Based Delegation Framework
Our framework supports delegation handling in workflow systems. Several issues are derived from our framework. The issues and corresponding solutions are discussed in this Chapter. First, user assignment loop problem may occur in the repeated delegation, and this problem is presented in Section 4.1 In section 4.2, the separation of duty principle in our framework is introduced. Organization role conflict problem in Section 4.3 gives a new issue between organization role and process role.
4.1. User Assignment Loop
If a delegated task is delegated to its delegator user, user assignment loop problem happens. Normally, a user doesn’t delegate his task to himself. Therefore, the user assignment loop only occurs in a repeated delegation.
Fig.4.1 presents an example of user assignment loop problem. Task1 is assigned to User1 through Role1. Assume that User1 delegates his task, Task1, to User2, and delegates Task1 to User3 due to an emergency task. Furthermore, User3 is accidentally unavailable, after he accepts the delegated task. If Task1 is automatically now assigned to User1 by the workflow engine, the user assignment loop problem takes place under this scenario.
To prevent this problem, the delegator users are needed to be recorded. There are two ways to record the delegator users of a delegated task. One is marking method, and the other one is tracing method. The two methods are introduced in following sections.
Fig.4.1 User assignment loop problem
4.1.1. The Marking Method for User Assignment Loop Problem
In marking method, the id of the delegated task is stored in a table named d_task which is associated with the delegator user as an extended attribute. When a delegation happens, the delegated task id is put into the d_task table associated with the delegator user. Moreover, while the repeated delegation occurs, the delegated task id is recorded in all delegator users’ d_task tables respectively. As described in Chapter 3, when the original user revokes his delegated task or the task completes, the delegated task id is kick off from those user who has it in his/her d_task.Algorithm 4.1 AALMm (Analysis of Assignment Loop with Marking Method) describes the marking method. This algorithm removes users who might cause the user assignment loop from the user set generated by the collecting algorithm and analyzed by other analysis methods. Each candidate user’s d_tasks table is checked if there is a recorded task id equaled to the delegated one. In case it is true, this user is deleted from the delegatee user set.
Algorithm 4.1 (Analysis of Assignment Loop with Marking Method) Input:
A user set C
The delegated task t Output:
A delegatee user set D without the user assignment loop problem AALMm
4.1.2. Tracing Method for Use Assignment Loop Problem
In tracing method, the id of the delegator user is stored in a table, named r_task, which is associated with the temporal delegatee role. When a delegation happens, the delegator user’s id is put into the r_task table associated with the temporal delegatee role. Furthermore, while the repeated delegation occurs, all ids of the delegator users are recorded in the r_task table. As described in Chapter 3, when the original user revokes his delegated task or the task completes, the temporal
delegatee role is removed, and the r_task table on this role is also deleted.
Algorithm 4.1 AALTm (Analysis of Assignment Loop with Tracing Method) describes the tracing method. The purpose of this algorithm is the same with the algorithm AALMm. The r_tasks table binding on the temporal delegatee role related to the delegated task is checked.
Algorithm 4.2 (Analysis of Assignment Loop with Tracing Method) Input:
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) Input:
03 If t.state = submit
Algorithm 4.3, AWSDP (Analysis of Weak SoD Principle), is executed when the delegated tasks is typed “decision” and under the constraint of weak SoD principle.
In AWSDP, all the users which potentially perform any decision tasks in the process are removed from the result set. To achieve the goal, the execution states of tasks are considered. For a submitted task, if the task is not delegated, the original performer is considered, otherwise only the delegatee user is considered. To a ready or a running task, because revocation might take place, both the original performer and the delegatee user (if any) must be considered.
4.2.2. Analysis method of Strong SoD
Strong SoD restrict that all tasks in one process must be performed by different users. Since the collecting algorithm collects users only from the process role repository, the collecting algorithm find no delegatee users under strong SoD. For this reason, when delegating one task with strong SoD constraint, a new collecting
algorithm is brought up for fitting strong SoD by using organization role repository.
When one task is set to strong SoD constraint, Algorithm 3.1 is not used to select the delegatee users of this task in order not to against this constraint. A new selection algorithm is used to collect candidate users from the organization role repository.
Algorithm 4.4 presents this method.
Algorithm 4.4 (Strong SoD User Collecting Algorithm) Input:
11 D = AUALTm(D, t) 12 End
First, the delegator user’s supervisors in organization are collected. Moreover, users with the equal organization level to the delegator user are picked. Second, the system deletes users whose work count is out of their maximum workload or process role appeared in the process repository of delegated task. This action is used to achieve the main concept of separation of duty. Third, the user assignment loop checking algorithm in Section 4.1 is executed to prevent the loop problem. After executing this algorithm, a delegatee user set based on organization role is constructed without against the strong SoD principle.
4.3. Organization Role Conflict
The delegatee role may be assigned to a user whose organization role is lower than the delegator user. A problem is raised that some decision tasks of a supervisor may be performed by his subordinate after delegation. Fig.4.5 presents an example of organization role assignment and process role assignment. In this organization, Tom is Rose’s supervisor, and Elvis is Rose’s subordinate. In one project of this organization, the project manager role is played by Tom, and the QA and RD roles are respectively assigned to Rose and Elvis. It is noticed that the roles are hierarchical in organization role structure, but those in process roles are not totally hierarchical. The project manager, QA, and RD roles are project-oriented role.
Therefore, they belong to process roles.
Fig.4.3 Organization role assignment and process role assignment
Fig.4.6 shows a process of asking leave of absence. If someone in this project cannot attend scheduled meetings, he starts this process. He sends the form of asking leave of absence to the project manager to approve this request. In this scenario, approving absence requests task is assigned to the project manager, Tom. Assume that someday Tom is accidentally unavailable, and the workflow engine automatically delegates the approval task to Elvis. A strange situation is brought about that Rose’s absence request is approved by Elvis, i.e. the supervisor’s absence request is approved by his subordinate.
Fig.4.4 Task assignment with process role
The primary reason to cause organization conflict is that tasks are assigned to the
process role instead of being assigned to the organization role. Section 3 has described the advantages of separating role into these two types. However, the implicit problem is coming up with this special assignment of role, tasks, and users.
From company ethics viewpoint, an engineer cannot approve the manager’s absence request. For not to violate such company ethics problem, the delegatee user’s organization role is needed to be checked when collecting the candidate users.
Considering the type of task, the execution path and result is not changed when executing general task. This means that no organization role conflict in delegating general tasks. But the decision type task may change. Thus, in order not to cause the organization role conflict problem, decision tasks are not allowed to be delegated to users with lower organization roles. Algorithm 4.5 gives this solution of checking the organization role conflict.
Algorithm 4.5 (Organization Role Conflict Checking Algorithm) Input:
06 Endfor 07 End
The users whose organization roles are lower then the delegator user are deleted.
This step ensures no subordinate of the delegator user is collected into the delegatee user set. It prevents the primary reason to cause organization role conflicts.
There are lots of departments in modern enterprises. And the process in this environment usually requires inter-department cooperation. When delegations happen in such environment, the organization role conflict problem may apparent much easier. This conflict is called inter-department organization role conflict.
Using Fig.4.3 as an example, Rose is the supervisor of engineer department, and Peter is sales department manager. There is a project to be carried out by the two departments to carry out, but one collaborate process is created. In this project, Rose is the project leader, and Peter is a member of this project. In process view, Peter’s absence request is approved by Rose. Rose is accidentally unavailable one day, and project leader role is delegated to Eric. Peter’s absence request is approved by Eric in this scenario. This breaks the company ethics, and inter-department organization role conflict occurrs. This problem is viewed as a special case in organization role conflict. Decision type tasks bring up this conflict. The solution of this problem is similar to organization conflict. In order not to let the decision type task delegate to the subordinate of other departments, the checking condition is modified to check the level of organization role. Algorithm 4.6 presents inter-department organization role conflict checking algorithm.
Algorithm 4.6 (Inter-Department Organization Role Conflict Checking Algorithm)
Input:
A user set C
The delegator user d Output:
A user set D IDORCCA 00 Begin
01 For each u∈C, do
02 If u.org_role.org_level ≦ d.org_role.org_level 03 Remove u from C
04 Endif 05 Endfor 06 End
Algorithm 4.6 Inter-department organization role conflict checking algorithm Line02 changes the checking condition of Algorithm 4.5. In Algorithm 4.5, the checking condition is organization role. If the delegatee user’s organization role is lower than the delegator user’s, he is deleted from delegatee user set. In Algorithm 4.6, the checking condition is the organization level. If the level of delegatee user is smaller than the delegator user’s, he is erased from the delegatee user set.
4.4. Integration of the analysis methods
After describing the analysis methods, we use a flow to integrate these methods.
After describing the analysis methods, we use a flow to integrate these methods.