Policy Rules

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:

Name and description of the rule are used for configuration management and diagnostics. The rule name will be displayed in the log files when the rule is processed.
Focal object that the rule applies to. This defines the object that is being changed. E.g. this is the user that receives a new assignment. Or it is the role that is being created.
Target object (optional). This is used when applying the rule to the assignment. The target object represents the target of the assignment, which is usually a role, org or a service.
Condition (optional) when the rule should be applied. If the condition is not specified it is assumed to be true.
Policy constraints specify when the rule is triggered. E.g. the rule may be triggered when a role is assigned, when the role is changed, when the role is not assigned to any user or when it is assigned to too many persons and so on.
Policy situation is an identifier of a situation which is the result of this rule. The situation identifier is stored together with the affected object or assignment and it can be used for reporting.
Policy actions specify the actions that are to be taken when the rule is triggered. The actions may range from strong enforcement of the rule (i.e. prohibit the operation) through Approval to a very mild actions such as notifications.

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:

Assignment approvals: policy rules may be used to change the default assignment approval schemes in a very flexible and scalable fashion.
Role lifecycle management: policy rules may be used to enforce approvals of new roles before they are used in production. They may be used to approve changed role definitions. And so on.
Compliance (not yet implemented): policy rules may be used to set policy situation in the affected objects. The policy situation may be used in reports to identify the objects that violate compliance rules, to report the percentage of compliant vs non-compliant objects and so on.
Flexible notifications, ad-hoc recertification and other governance and compliance features that are planned for future midPoint versions.

Rule Content

Policy Constraints

TODO

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

TODO

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

TODO

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

History

This feature is available only in midPoint 3.6 and later.

This feature was also available in midPoint 3.5. However even in midPoint 3.5 this feature was considered EXPERIMENTAL except when used for Role Lifecycle and assignment-based approvals. This mechanism was only partially implemented in midPoint 3.5.

Compliance

This feature is related to the following compliance frameworks:

Introduction

Rule Content

Policy Constraints

Policy Situation

Policy Actions

Rule Definition

Global Policy Rules

Direct Rule Definition

Metarole-Based Rule Definition

Policy Rule Exceptions

History

See Also

Compliance