Duen-Ren Liu, Mei-Yu Wu, Shu-Teng Lee. 2002. "Role-based authorizations for workflow systems in support of task-based separation of duty"

Most literature ha addressed SoD constraints in role-based authorizations of workflows.

• However, they do not consider SoD constraints in relation to various duty-conflict relationships and execution dependencies among tasks.
• Moreover, they do not consider authorization planning for assigning users/roles to workflow tasks.

Workflow

• a set of tasks, and their order of execution, according to control flow dependencies
• various tasks in a workflow are typically performed by multiple collaborating users/roles in an organization
• for two roles Ri and Rj, Ri > Rj, if the position of Ri is higher than the position of Rj in the organization

WfMS generally include process definition tools and workflow engines

• process definition tools - define a workflow (process definition) during the period of design
• workflow engine - governs the run-time enactment of workflow according to the process definition
• workflow/process instance - single execution of a workflow
• each instance represents a separate execution of the process, and has its own associated process instance data
• task instance - execution of a task (activity) within a workflow instance

Execution dependency

• Two tasks Ti and Tj are execution-dependent tasks, denoted as Ti ~ Tj, if they are correlated, such that the execution (processing) of one task (Ti) depends on the execution (processing) of the other task (Tj).
• Ti x Tj indicates that tasks Ti and Tj are not execution-dependent.
• Execution dependency among tasks can generally be derived from the accessed data objects. If task Ti accesses data objects that are created/modified by task Tj, then the execution of Ti depends on the execution of Tj.

Duty-conflict relationships

• Duty-conflict tasks - Two tasks Ti and Tj are duty-conflict tasks, denoted as Ti + Tj, if they have duty-conflict relationships; that is, their implicit task-duties conflict.
  
  • Duty-conflict relationships can be further distinguished
    into duty-balancing and duty-supervising relationships.
• Duty-balancing tasks - Two tasks Ti and Tj are duty-balancing tasks, denoted as Ti = Tj, if the implicit task-duty of Ti (Tj) is to review task Tj (Ti). Ti and Tj have an equal level of task duty.
• Duty-supervising tasks - Task Ti supervises task Tj, denoted as Ti > Tj, if the implicit task-duty of Ti is to supervise task Tj. Ti has a higher task-duty than Tj.
• If Ti has a higher task-duty than Tj, Ti must be performed by a role with a higher position than the role that performs Tj.

Authorization rules for SoD
Static SoD [role and task]

• If task Ti and task Tj have a duty-conflict relationship, and role R was authorized to perform task Ti, then role R cannot also be authorized to perform task Tj.

Static SoD [user, role, and task]

• If tasks Ti and Tj have a duty-conflict relationship; roles Rx and Ry are authorized to perform tasks Ti and Tj, respectively; also, if role Rx was assigned to user S, then role Ry can not also be assigned to user S.

Dynamic SoD - enforces SoD within the user’s current active sessions

• Tasks Ti and Tj have a duty-conflict relationship. If role Ry was authorized to perform task Tj; role Rx was authorized to perform task Ti, and user S has activated role Rx, then user S can activate role Ry but can not execute task Tj in role Ry.

Execution-dependent SoD - enforces SoD across current active sessions and previous (historical) sessions

• Tasks Ti and Tj are duty-conflict and execution-dependent tasks (Ti + Tj and Ti ~ Tj). User S executed task Ti in role Rx, and role Ry is authorized to perform task Tj. User S can activate Ry , but user S cannot execute task Tj in role Ry .

Dynamic SoD for duty-supervising tasks

• Users SA and SB activate roles Rx and Ry to execute task Ti and Tj, respectively. If Tasks Ti and Tj have a duty-supervising relationship, Ti > Tj, role Rx must have a higher position than role Ry.

Execution-dependent SoD for duty-supervising tasks

• If user SB has executed task Tj in role Ry ; SA activates Rx to execute task Ti; tasks Ti and Tj are duty-supervising and execution-dependent tasks, then role Rx must have a higher position than Ry .

Authorization model for workflows
Role-task planning algorithm

• The algorithm first invokes the GenExecDependency( ) function to generate the execution dependency among tasks of the workflow W.
• The algorithm then invokes the recursive function RoleAssignment( ) to generate the
  set of all valid role-task assignments in the input workflow.
• Initially, valid_roles(Ti) is the set of roles that are capable to execute the current task Ti.
• According to the roles previously assigned to tasks and the SoD constraints, roles that are not valid to activate Ti are excluded from valid_roles(Ti).
• Considering each previously assigned task Tj, where Tj and Ti have execution
  dependency (Tj ~ Ti), valid roles for task Ti must exclude the roles assigned to Tj that has a duty-conflict relationship with task Ti (Tj + Ti).
• Moreover, if Ti and Tj have a duty-supervising relationship, Ti > Tj, then valid
  roles of task Ti must have a higher position than the role assigned to Tj.
• After the SoD verification has been conducted, valid_roles(Ti) is the set of roles that can validly activate the current task Ti.
• The while-loop considers each role in valid_roles(Ti) as a seed to explore possible role-task activation plans by recursively finding role assignments for the subsequent task Tk in Tlist.
• If the current task is the last task in Tlist, then a valid role-task assignment of
  the workflow has been found.
• A new RTplan, an list, is created to record the role
  assignments according to the assigned-role(Tj), for each task Tj in Tlist. The RTplan is added to the AllRTplans.
  
• If no valid role-task assignment is found, then the algorithm returns a failure; otherwise, it returns success.

AND/XOR split structure (a little unclear what this is)
AND-SPLIT structure splits the workflow execution into multiple parallel paths (tasks) that are all executed.
XOR-SPLIT structure splits the workflow execution into multiple mutually exclusive alternative paths (XOR-paths), only one of which is executed.

• Tasks in different XOR-paths are not executed in the same workflow instance. Thus, no execution dependency exists among tasks in different XOR-paths.

User-role task planning algorithm

• The algorithm primarily invokes the recursive function UserAssignment( ) to find a valid user-role-task assignment of the input workflow based on the valid RTplan generated by the role-task planning algorithm.
  • The UserAssignment( ) function determines valid user assignments for current pair by recursively finding user assignments for subsequent in
    RTplan.
  • The assignments must satisfy the SoD constraint that no duty-conflict (duty-supervising) tasks are assigned to the same user.
    
• If no valid user-role-task assignment is found, the algorithm returns failure; otherwise, it returns success.

Plan-adjust algorithm

• The workflow engine may store some RTplans in advance, without storing a URTplan. The user assignments are then determined in run-time to enact each task, using the
  user-role-task planning algorithm.
• An alternative approach is to store some RTplans and some URTplans in advance. The enactment of a workflow is based on the chosen activation plan.
  

The plan-adjust algorithm is invoked when the planned user, assigned to activate the current task, is not available, or when the run-time activation of the current task by the planned user violates the constraints of dynamic SoD variations.

• The URTplan-adjust( ) algorithm finds another valid URTplan, called NUplan, from URTplanSet, where NUplan follows the actual activation of task Ti, , for i = 1 to k - 1, such that the activation of current task Tk , , satisfies the constraints of dynamic SoD variations.
• The RTplanadjust() algorithm finds another valid RTplan, called NRplan, from RTplanSet, where NRplan follows the actual activation of task Ti, , for i = 1 to k - 1.
• The algorithm then finds a valid URTplan, called NUplan, based on NRplan and the actual activation of task Ti, , for i = 1 to k - 1, by invoking the UserAssignment(NRplan; Rk ; Tk) algorithm.
• The activation of Tk , , in NUplan, must satisfy theconstraints of dynamic SoD variations.

Conclusions

• First, the proposed system requires that enterprises plan the capabilities of roles and users in advance. However, enterprises may not have clearly identified the capabilities of roles and users. The policy of SoD may not be specified in organizations. To implement the proposed system in enterprises, a re-engineering process is required to adjust organizations’ operational procedures for specifying roles, users and security policy. Accordingly, the proposed system is more complex and increases the workload required for security validation.
• Second, the proposed system enforces a strict security control. In practice, an enterprise may require flexibility to adapt to dynamically changing business environments. Strict authorization enforcement can achieve SoD and thus prevent fraud, by sacrificing flexibility and convenience.