Segregation of Duties

Last modified 24 Jul 2025 08:58 +02: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 of 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. 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

The following role excludes the role with OID 12345678-d34d-b33f-f00d-987987987988. This means that that the Judge role cannot be assigned together with the referenced role at the same time. An attempt to do so will result in an error. The exclusion is considered to be bi-directional 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 result in a failure. In midPoint 3.5 and later, the exclusion is defined by using the policy rules mechanism:

<role>
    <name>Judge</name>
    <inducement>
        <construction>
            <resourceRef oid="ef2bc95b-76e0-59e2-86d6-3d4f02d3ffff" type="ResourceType"/>
        </construction>
    </inducement>
    <assignment>
        <policyRule>
            <name>excluded-role</name>
            <policyConstraints>
                <exclusion>
                    <targetRef oid="12345678-d34d-b33f-f00d-987987987988" type="RoleType"/>
                </exclusion>
            </policyConstraints>
            <policyActions>
                <enforcement/>
            </policyActions>
        </policyRule>
    </assignment>
</role>

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 MID-8299. We are considering an improvement that would weaken this definition (see MID-8572).

Policy Actions

Policy Rules have two parts important for role exclusion configurations: constraints and action. Constraints part defines which roles are exclude which roles. The action part define what to do when such an exclusion is detected. There are three options:

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

  • 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.

  • 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. (Optionally you can request recording the situation in the assignments by using "record" policy action.)

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

Exclusion Class

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

For example, the following example illustrates "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.

See Also

Compliance

This feature is related to the following compliance frameworks:

Was this page helpful?
YES NO
Thanks for your feedback