Separation of Duties (SoD) – modelling patterns

The following is a list of the separation of duties patterns supported by DCR process models.

IdDescriptionModel
1A purchase request must be approved by a different person other than the one who issued itModel
2Alice 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 caseModel
3A purchase request must be approved by a different person other than the one who issued it.Model
4If 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 requestsModel
5The activity Act1 must contain at least N unique roles.A senior programmer and a programmer should be involved in a pair programming activityModel
6If two activities are independent (for instance, they need to be executed in parallel), they are required to be done by different rolesModel
7If 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 testingModel

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.

Related Release notes

No related documentation found.

Related Videos

No related videos found.

Related Articles

No related articles found.
LinkedIn
Share