Table of Contents
The following is a list of the separation of duties patterns supported by DCR process models.
| Id | Description | Model |
| 1 | A purchase request must be approved by a different person other than the one who issued it | Model |
| 2 | Alice and Bob are caseworkers, and Charlie is a manager. A caseworker (different than the one that has run the case) must revise the case before reaching a conclusion. The manager cannot revise the case | Model |
| 3 | A purchase request must be approved by a different person other than the one who issued it. | Model |
| 4 | If Adam is a manager, he is also an employee, which would allow him to both file travel requests (as an employee) and approve them (as a manager). However, he cannot approve his own requests. Charlie (as a manager) can approve Adam's requests | Model |
| 5 | The activity Act1 must contain at least N unique roles.A senior programmer and a programmer should be involved in a pair programming activity | Model |
| 6 | If two activities are independent (for instance, they need to be executed in parallel), they are required to be done by different roles | Model |
| 7 | If two tasks Act1 and Act2 correspond to different subprocesses Sub1 and Sub2, they need to be assigned to different roles.Example: The coding and acceptance testing are two separate processes. For a given PBI, if you have start coding your solution, other person needs to perform acceptance testing | Model |
SoD 1 - Cannot approve my own request
Definition:
[1] Given two activities A and B in a precedence rule, the agent performing A should be different than the agent performing B.
[2] Of two sequential tasks A and B, if A was performed by user R, then B must not be performed by R.
Example:
a purchase request must be approved by a different person other than the one who issued it.
This pattern requires us to remember the distinction between events and labels, and to limit when an event is enabled depending on the execution of other events.
In the above example, we have two events: issuePurchaseRequest (with label "Issue purchase request"), and approveRequest (with label "approve request").
Notice that approveRequest cannot be performed by the user that performed issuePurchaseRequest (but not vice-versa). This require us to restrict when approveRequest is enabled for a user.
To restrict the enabledness depending on users, we will define a user expression (available in Resources -> User Expression). The expression
__USER__!=IssuePurchaseRequest@UserId
Let us decompose this expression. Each executed event in DCR has an user ID. For those events that have not been executed, such ID is null. The variable __USER__ has per value the existing user ID, and cannot be altered. Overall, the expression will be evaluated as true if a UserID different than who executed IssuePurchaseRequest is simulating/executing the graph. The expression will also evaluate to true if IssuePurchaseRequest has not yet being executed (thus IssuePurchaseRequest@UserId = null)
References:
[1] Awad, Ahmed, Emilian Pascalau, and Mathias Weske. "Towards Instant Monitoring of Business Process Compliance." EMISA Forum. Vol. 30. No. 2. 2010.
[2] Botha, Reinhardt A., and Jan H. P. Eloff. "Separation of duties for access control enforcement in workflow environments." IBM Systems Journal 40.3 (2001): 666-682.
SoD 2: 4-eyes principle
Definition:
Given two users User1, User2 such that both users are associated with role R, and the graph contains activities A and B in precedence, if A is executed by Par1, then B should not be executed by Par1, and vice-versa (wrt to Par2)
Example:
Alice and Bob are caseworkers, and Charlie is a manager. A caseworker (different than the one that runs the case) must revise the case before reaching a conclusion. The manager cannot revise the case.
The only difference between this example and SoD 1 is the clear distinction of activity enabledness depending on a role assignment. In this case, Charlie is associated to the manager role, and therefore cannot execute reviseCase. Dynamic role assignemnt, role delegation, etc, is normally provided by an external system (such as KMD workzone), so in our example we limit the description to a fixed set of users and user roles.
SoD 3: 4-eyes principle with multiple role assignments
Example:
If Adam is a manager, he is also an employee, which would allow him to both file travel requests (as an employee) and approve them (as a manager). However, he cannot approve his own requests. Charlie (as a manager) can approve Adam's requests.
Explanation: while SoD 2 has describes a separation of duties assuming that one user has only one role in the organization, in many cases we have access control systems that allow multiple role assignments for users. Such an assignment might leak permissions empowering users to use their credentials to be requester and judge at the same time. The solution used is a combination of the selection of appropriate user expressions (as in SoD 1) with the pairing to an access control system, as the one provided via the open case manager or Workzone.
SOD 5: Cardinality constraint
Definition: A subprocess must contain at least N unique roles.
Example: A senior programmer and a programmer should be involved in a pair programming activity
We have relaxed this pattern to "the subprocess must contain exactly N unique roles". To model the "at least" we will need to extend the pattern non-pending activities so the subprocess is accepted once N activities have been executed, all of them in different roles.
This pattern assumes that participant -> role mappings create a partition. The access control system of your ACM should guarantee that policy.
SOD 6: Activity Independence
Description: If two activities are independent (for instance, they need to be executed in parallel), they are required to be done by different roles
The trick of this pattern is to encode the mutual circularity between events. Since we do not know which event will be triggered first, we need to establish user expressions to both, so in case A goes triggered first, it modifies the pool of users that can do B, and vice-versa.
