Introduction

Policy rules are very powerful mechanism that spans a very wide range of use cases. It can be used to define role approval, lifecycle, policies such as segregation of duties, notifications and other governance and compliance rules.

Each policy rule has the following parts:

Some of these parts may be implicit. E.g. if the rule is defined as a high-order inducement in the metarole then the focal object or target are implicit and does not need to be explicitly specified.

The policy rules are used to implement wide variety of mechanisms:

Rule Content

Policy Constraints

This section needs to be expanded. However, documentation work is similar to the development work in that it takes time and that it needs funding.
If you are midPoint subscriber, you can request that we complete this section and we will do that as soon as possible. Or you may use the option to sponsor completion of midPoint documentation.

In case that several policy rule constraints are specified at the same time then logical AND is assumed between them. I.e. all the constraints must be satisfied for the rule to get triggered. This is a natural way in which to express overlapping time intervals, modification of several properties at the same time and so on. However, this may be counter-intuitive for some cases, such as exclusion constraints. However, even for exclusion this approach makes complete sense. The logical AND between exclusion may be used to implement "triangular" exclusion and other advanced exclusions schemes. It is just a matter of getting used to.

In case that you need a logical OR between several constraints you just need to re-formulate them into several policy rules. Each of the policy rules is triggered individually, therefore implementing logical OR operation.

Policy Situation

This section needs to be expanded. However, documentation work is similar to the development work in that it takes time and that it needs funding.
If you are midPoint subscriber, you can request that we complete this section and we will do that as soon as possible. Or you may use the option to sponsor completion of midPoint documentation.

Policy Actions

This section needs to be expanded. However, documentation work is similar to the development work in that it takes time and that it needs funding.
If you are midPoint subscriber, you can request that we complete this section and we will do that as soon as possible. Or you may use the option to sponsor completion of midPoint documentation.

Rule Definition

The policy rules can be defined at several places in the system. Each definition method applies to different focal/target objects and have different manageability and scalability properties. However all the rules are evaluated in the same way regardless of the specific method of their definition.

Global Policy Rules

Policy rules can be defined in system configuration object. In this case the rule is evaluated for every operation and it applies to all objects that are matched by the rule focus and target selectors. This method of rule specification has a global scope and therefore the administrator can have high confidence that the rule is applied to all objects to which it should be applied. However it may have scalability impact if not used properly. Evaluation of the focus and target selectors is usually very fast, therefore a reasonable number of global rules with simple selectors should have only negligible impact on system performance. However, large number of rules with complex selectors and conditions may significantly impact the performance.

The global policy rule is defined in a system configuration like this:

<systemConfiguration>
    ...
    <globalPolicyRule>
        <name>immutable-role</name>
        <policyConstraints>
            <modification>
                <operation>modify</operation>
            </modification>
        </policyConstraints>
        <policyActions>
            <enforcement/>
        </policyActions>
        <focusSelector>
            <type>RoleType</type>
            <filter>
                <q:equal>
                    <q:path>riskLevel</q:path>
                    <q:value>high</q:value>
                </q:equal>
            </filter>
        </focusSelector>
    </globalPolicyRule>
    ...
</systemConfiguration>

This rule applies to all role that have high risk level. The rule enforces the modification constraint. This simply prohibits any role modification. An attempt to modify such role will result in an error (policy violation).

Direct Rule Definition

The rules may also be defined directly in the objects to which they apply. In this case the rules are defined in the assignments:

<role>
    <name>Immutable role</name>
    <assignment>
        <policyRule>
            <name>immutable-role</name>
            <policyConstraints>
                <modification>
                    <operation>modify</operation>
                </modification>
            </policyConstraints>
            <policyActions>
                <enforcement/>
            </policyActions>
        </policyRule>
    </assignment>
</role>

This is the same rule as in the previous case. The rule prohibits role modification. The focal object is implicit in this case - it is the object that contains the rule. There is no need for an explicit focus selector.

However, this method is not very practical - it is not very manageable. It is difficult to manage large number of roles when the rules are specified in each role separately. Therefore this approach is not recommended for production use. The metarole-base approach is recommended instead.

Metarole-Based Rule Definition

Policy rules can be defined in the assignments. Which means they can be taken to the meta-level using the usual midPoint mechanism of metaroles. If all the sensitive roles have the same meta-role assigned then the rule can be easily defined in the metarole as (high-order) inducement. Like this:

<role>
    <name>Untouchable metarole</name>
    <inducement>
        <policyRule>
            <name>untouchable</name>
            <policyConstraints>
                <modification/>
            </policyConstraints>
            <policyActions>
                <enforcement/>
            </policyActions>
        </policyRule>
    </inducement>
</role>

The policy rule is placed in the inducement, not in the assignment here. Therefore the rule does not apply to this role itself. It will apply to all the roles that have this role assigned. This is simple and scalable way how to define policies that apply only to some role types, organizational hierarchies, services and so on. See the Roles, Metaroles and Generic Synchronization page for more details about the meta-role mechanism.

Policy Rule Exceptions

They say that there is always an exception to any rule. Whether that is the truth or not, there is often a need to make an exception from a policy rule. Common use case is an exception from Segregation of Duties policy: the policy states that certain roles cannot be combined. But if the request goes through a special approval then it may be allowed. This may seem like a straightforward mechanism. But it is not. It is not enough to simply override the policy and allow assignment of conflicting roles. Such assignment will the appear in every review, compliance report, the approver will be asked for re-approval after even a minor change in the assignment and so on. It is necessary to remember the decision to fully support this scenario: to create an exception.

MidPoint has a mechanism how to support exceptions from the policy rules. The policy exceptions are stored in the assignment that triggered the policy rule. As long as the exception is stored there then the referenced policy rule is deactivated for that specific user and that specific assignment. It will not be subject to re-approvals, it will not be raised as an issue in compliance reports and so on. However, the record of the exception is maintained in the assignment. In the future that information can be used e.g. to report approved rule exceptions, to re-certify then and so on.

See Also