Gradual Enforcement of Policies

Last modified 15 Jul 2025 14:27 +02:00
Gradual policy enforcement feature
This page describes Gradual policy enforcement midPoint feature. Please see the feature page for more details.
Table of Contents

MidPoint contains a powerful mechanism of policy rules and policy objects, which can be used to enforce various policies, such as segregation of duty policies. However, outright enforcement of new policies can be very inconvenient and disruptive. As a new policy is applied, it is likely that there are existing violations of the policy. If such a policy is immediately enforced, users that are in violation of such policy will be impacted. MidPoint takes policy enforcement very seriously. MidPoint will deny any operation on such users until they are compliant with the policy. However, this means that those users are efficiently paralyzed. Therefore, it is a much better idea to enforce the policy gradually rather than immediately.

Procedure

To enforce your policies gradually:

  1. Defined your policy using policy rules.

  2. Set the action part of your policy rule to record.

  3. Wait until midPoint recomputes objects affected by the policy (or trigger the recomputation manually). The recompute process marks all objects that violate the policy using object marks.

  4. Analyze the marked objects using reports, dashboards, or a simple search in the user interface.

  5. Fix any policy violations. This may take quite a long time. However, as the policy is not enforced yet, there will be no disruption to the normal system operation.

  6. When all policy violations are eliminated, switch the policy rule action to enforce. From this point, midPoint will not allow any new policy violations, strictly enforcing the policy.

Example

This example demonstrates a gradual application of a segregation of duties (SoD) policy. SoD is a very good example of the importance of gradual policy enforcement as it is very likely there will be policy violations, especially in systems with a large user base and a large number of roles.

  1. The first step is to define a SoD policy rule, while setting the action to record.

    In this case, we are trying to mutually exclude the Financial auditor and Invoice clerk roles. Therefore, there is a simple policy rule in the Financial auditor role that excludes Invoice clerk role.

    <role>
    <name>Financial auditor</name>
    <assignment>
        <policyRule>
            <name>excluded-invoice-clerk</name>
            <policyConstraints>
                <exclusion>
                    <!-- Invoice clerk role -->
                    <targetRef oid="82d0d8a6-9459-46e3-87e8-3f469f34fd2d" type="RoleType"/>
                </exclusion>
            </policyConstraints>
            <markRef oid="00000000-0000-0000-0000-000000000811"/>
            <policyActions>
                <record/>
            </policyActions>
        </policyRule>
    </assignment>
</role>

    The rule has policyActions set to record, therefore it will not interfere with operations. It will only record the situation using the Exclusion violation object mark.

    Since midPoint 4.8, the mark reference (markRef) needs to be explicitly specified.

  2. Next, midPoint recomputes all users, to make sure that the updated policy is applied. Users that are in conflict with the policy will be marked with the Exclusion violation mark.

  3. Now we need to locate the conflicting objects. You can use search to locate the marked objects, or, more conveniently, you can use a pre-defined widget in the compliance dashboard (for SoD):

    Compliance dashboard SoD violations

    The dashboard widget leads to the list of users with SoD conflicts.

  4. Knowing where the conflicts are, we need to fix them one by one. You can monitor your progress in the compliance dashboard.

  5. Once you address all violations, change the policy action to full enforcement by changing policyActions to enforcement.

    <role>
    <name>Financial auditor</name>
    <assignment>
        <policyRule>
            <name>excluded-invoice-clerk</name>
            <policyConstraints>
                <exclusion>
                    <!-- Invoice clerk role -->
                    <targetRef oid="82d0d8a6-9459-46e3-87e8-3f469f34fd2d" type="RoleType"/>
                </exclusion>
            </policyConstraints>
            <markRef oid="00000000-0000-0000-0000-000000000811"/>
            <policyActions>
                <enforcement/>
            </policyActions>
        </policyRule>
    </assignment>
</role>

  6. The policy is now fully enforced and any attempt to assign conflicting roles will trigger an error.

See Also

Compliance

This feature is related to the following compliance frameworks:

Was this page helpful?
YES NO
Thanks for your feedback