Segregation of Duties

Last modified 19 Dec 2025 08:17 +01:00
Segregation of duties feature
This page describes configuration of Segregation of duties midPoint feature. Please see the feature page for more details.
Table of Contents

Segregation of Duties (SoD) is a mechanism that prevents accumulating too much power in the hands of a single person. It places constraints on assignments of entitlements to users. For example, a SoD may prevent a single user from creating a request and also approving it.

In its simplest form, the Segregation of Duties is implemented at the RBAC level by role exclusions. It means that roles that exclude each other cannot be assigned to the same user at the same time, or that such a situation is followed by another action (e.g., an extra approval workflow). This is the basic SoD mechanism that is implemented in midPoint now. More complex SoD rules will be implemented in the future.

Role exclusion definition

SoD is defined by using the policy rules mechanism. It contains two parts important for the role exclusion configuration: policyConstraints and policyActions. The role exclusion definition is to be placed within the policyConstraints of the rule. It defines which roles are mutually exclusive.

<role>
    <name>Scrum Master</name>
    <assignment>
        <policyRule>
            <name>Developer Exclusion Policy Rule</name>
            <policyConstraints>
                <exclusion>
                    <targetRef relation="org:default" type="c:RoleType">
                        <filter>
                            <q:text>name = 'Developer'</q:text>
                        </filter>
                        <resolutionTime>run</resolutionTime>
                    </targetRef>
                </exclusion>
            </policyConstraints>
            <policyActions>
                <!-- Reaction to the exclusion violation -->
            </policyActions>
        </policyRule>
    </assignment>
</role>

The role above excludes the Developer role. This means that an attempt to assign the Scrum Master role when the Developer role is already assigned will result in a specific action. The action may forbid assigning both the Scrum Master role and the Developer role to the same person. It may also mean that one person can have both roles assigned, but it has to be approved by a higher manager first. The exclusion is considered bidirectional, even if it is defined in only one of the two excluded roles. Therefore, the order of role assignment is insignificant. Whichever role is assigned as second will trigger the action.

Policy actions

The policyActions part defines what to do when an exclusion violation is detected. There are various policy actions available. The following options are the most common for implementing the SoD use cases:

  • Enforcement means that the role conflict is not allowed. Any attempt to assign conflicting roles will end up in an error.

    <role>
    <name>Financial Auditor</name>
    <assignment>
        <policyRule>
            <name>Accountant Exclusion Policy Rule</name>
            <policyConstraints>
                <exclusion>
                    <targetRef relation="org:default" type="c:RoleType">
                        <filter>
                            <q:text>name = 'Accountant'</q:text>
                        </filter>
                        <resolutionTime>run</resolutionTime>
                    </targetRef>
                </exclusion>
            </policyConstraints>
            <policyActions>
                <enforcement/>
            </policyActions>
        </policyRule>
    </assignment>
</role>

    In the example above, the Financial Auditor role excludes the Accountant role. As these two roles must not be assigned to the same person at the same time, the enforcement policy action is set. Therefore, an attempt to assign the Accountant role when the Financial Auditor role is already assigned (or vice versa) will not be successful, and the requester will receive an error message about the situation.

  • Pruning means that the conflicting roles are unassigned. When a new role is assigned, the existing roles that are in conflict with the new role will be unassigned.

    <role>
    <name>Product Student License</name>
    <assignment>
        <policyRule>
            <name>Product Employee License Exclusion Policy Rule</name>
            <policyConstraints>
                <exclusion>
                    <targetRef relation="org:default" type="c:RoleType">
                        <filter>
                            <q:text>name = 'Product Employee License'</q:text>
                        </filter>
                        <resolutionTime>run</resolutionTime>
                    </targetRef>
                </exclusion>
            </policyConstraints>
            <policyActions>
                <prune/>
            </policyActions>
        </policyRule>
    </assignment>
</role>

    In the example above, the Product Employee License excludes the Product Student License. To use resources efficiently, the company does not want to assign both types of licenses to the same person for the same product. However, the policy may be that the license that was assigned (or requested by a user) later is the preferred one we want to keep. With the prune policy action, an attempt to assign the employee license when the student license is already assigned will be successful, but the student license will be unassigned in the process. In the opposite situation, the employee’s license would be unassigned.

  • Approval means that the request will be subject to an additional approval. The approver may decide whether to allow assignment of conflicting roles. If the operation is approved, then it proceeds.

    <role>
    <name>Scrum Master</name>
    <assignment>
        <policyRule>
            <name>Developer Exclusion Policy Rule</name>
            <policyConstraints>
                <exclusion>
                    <targetRef relation="org:default" type="c:RoleType">
                        <filter>
                            <q:text>name = 'Developer'</q:text>
                        </filter>
                        <resolutionTime>run</resolutionTime>
                    </targetRef>
                </exclusion>
            </policyConstraints>
            <policyActions>
                <approval>
                    <compositionStrategy>
                        <order>100</order>
                    </compositionStrategy>
                    <approvalSchema>
                        <stage>
                            <name>security-officer</name>
                            <approverRef type="RoleType">
                                <filter>
                                    <q:text>name = 'Senior Manager'</q:text>
                                    <resolutionTime>run</resolutionTime>
                                </filter>
                            </approverRef>
                            <evaluationStrategy>firstDecides</evaluationStrategy>
                            <outcomeIfNoApprovers>reject</outcomeIfNoApprovers>
                            <groupExpansion>onWorkItemCreation</groupExpansion>
                        </stage>
                    </approvalSchema>
                </approval>
            </policyActions>
        </policyRule>
    </assignment>
</role>

    In the example above, we get back to the exclusion of the Scrum Master and the Developer roles. The company does not approve such job positions to be assigned to the same person by default, but there may be exceptions. Therefore, the approval policy action is set so each case can be examined. As a result, any attempt to assign the Developer role when the Scrum Master role is already assigned (or vice versa) will trigger an approval workflow. In this case, any member of the Senior Manager role can approve or reject the request.

  • Record means that the conflict will be recorded using a mark. The mark can be used to report violations and gradually enforce the policy.

    <role>
    <name>Tester</name>
    <assignment>
        <policyRule>
            <name>Developer Exclusion Policy Rule</name>
            <policyConstraints>
                <exclusion>
                    <targetRef relation="org:default" type="c:RoleType">
                        <filter>
                            <q:text>name = 'Developer'</q:text>
                        </filter>
                        <resolutionTime>run</resolutionTime>
                    </targetRef>
                </exclusion>
            </policyConstraints>
            <!--Built-in Exclusion violation mark -->
            <markRef oid="00000000-0000-0000-0000-000000000811">
                <description>Tester - Developer exclusion violation</description>
            </markRef>
            <policyActions>
                <record/>
            </policyActions>
        </policyRule>
    </assignment>
</role>

    In the example above, the company has decided that the product testing and the product development should not be performed by the same employees. Thus, a new policy was created, mutually excluding the Developer and Tester roles. However, as such a change will require updating employee contracts, we cannot take immediate action but need to choose a more subtle approach. Therefore, we use the record policy action, which will effectively mark each assignment that violates the newly created exclusion policy. This information can be later used in dashboards, reports, or in certification campaigns to review the current status and continuously enforce the newly created policy.

Exclusion class

MidPoint does not have a direct configuration for role exclusion classes (set of roles where each role excludes all other roles from the same class or from different classes). However, this configuration can easily be created and maintained by using role hierarchies and metaroles.

For example, the following configuration illustrates an "exclusion class" between executive and controlling roles. The controlling metarole defines exclusion of all executive roles:

<role>
    <name>Controlling metarole</name>
    <description>Excludes all executive roles using a filter</description>
    <inducement>
        <policyRule>
            <name>executive exclusion</name>
            <policyConstraints>
                <exclusion>
                    <targetRef type="RoleType">
                        <filter>
                            <q:text>subtype = "executive"</q:text>
                        </filter>
                        <resolutionTime>run</resolutionTime>
                    </targetRef>
                </exclusion>
            </policyConstraints>
            <policyActions>
                <enforcement/>
            </policyActions>
        </policyRule>
    </inducement>
</role>

The metarole above is to be assigned to controlling roles (where subtype is different from "executive", e.g., "controlling"). If the user has any controlling role assigned and attempts to have another role with subtype="executive" assigned, the request will be refused because of a SoD conflict. Thus, it is not possible to mix executive and controlling roles.

Limitations

Currently, the role exclusion mechanism ignores the time validity of individual assignments. Hence, if roles A and B are mutually exclusive, and a user has an assignment of A valid from Monday to Wednesday, and an assignment of B valid from Thursday to Sunday, these two are still considered to be in conflict.

(Technically, both roles are still assigned at the same time. Also, the two assignments cannot be effectively active at any moment.)

See also

Compliance

This feature is related to the following compliance frameworks:

Was this page helpful?
YES NO
Thanks for your feedback