<policyRule>
<policyConstraints>
<assignment>
<operation>add</operation>
</assignment>
</policyConstraints>
<policyActions>
<certification>
<definitionRef oid="540940e9-4ac5-4340-ba85-fd7e8b5e6686" /> <!-- adhoc-certification -->
</certification>
</policyActions>
</policyRule>
Ad-Hoc Certification
Sometimes it is necessary to implement something like this: "When a user appears in an organization, the new manager should certify all his assignments." Since midPoint 3.6 this kind of requirements can be met.
Two mechanisms are to be employed:
-
policy rules,
-
certification campaign definitions.
Policy rules can be configured to trigger creation of a new certification campaign (called ad-hoc certification campaign, to distinguish it from standard multi-object scheduled campaigns). Such a rule looks like this:
There are two interesting items here:
-
A policy constraint (lines 3-5) drives when the rule is triggered. In this case, it is when a new assignment to the holder of this policy rule is created. So, it is expected that this rule should be assigned to organization(s) for which we want to have ad-hoc certifications be started for all newcomers.
-
Certification policy action (lines 8-10) that tells about the certification campaign that should be started. More specifically, "definitionRef" points to the certification definition that prescribes how the certification should look like; e.g. how many stages should it have, how to select reviewers for these stages, and so on.
An example of such definition:
<accessCertificationDefinition>
<name>Ad-hoc certification</name>
<handlerUri>http://midpoint.evolveum.com/xml/ns/public/certification/handlers-3#direct-assignment</handlerUri>
<remediationDefinition>
<style>automated</style>
</remediationDefinition>
<stageDefinition>
<number>1</number>
<duration>P14D</duration>
<reviewerSpecification>
<defaultReviewerRef oid="00000000-0000-0000-0000-000000000002" type="UserType" /> <!-- administrator -->
</reviewerSpecification>
</stageDefinition>
<adHoc>true</adHoc>
</accessCertificationDefinition>
Note that this definition has no scopeDefinition
. It is not necessary, because the scope is defined as a single-object one, containing the object to which particular certification policy action was triggered.
But it can be present, if needed.
In such case, objectType
and searchFilter
parts of it are replaced by the type of current object, and single-object OID-based filter, respectively.
There can be more certification policy actions, and each can contain more certification definition references to be started. The current implementation is such that each of these campaigns is started independently. In the future we may implement some composition mechanism, similar to the one used for approval policy actions.
Note: The definition reference must be OID-based. Filter-based ones (evaluated at run time) are not supported now.
Starting certification after property change
This feature is not limited to situations where an assignment is created. A policy rule can be triggered also when one or more object items are modified. The following two examples describe starting ad-hoc campaign when (a) both employeeType and organization are changed, (b) either employeeType or organization (or both) are changed.
<policyRule>
<policyConstraints>
<modification>
<operation>modify</operation>
<item>employeeType</item>
<item>organization</item>
</modification>
</policyConstraints>
<policyActions>
<certification>
<definitionRef oid="540940e9-4ac5-4340-ba85-fd7e8b5e6686" /> <!-- adhoc-certification -->
</certification>
</policyActions>
</policyRule>
<policyRule>
<policyConstraints>
<modification>
<operation>modify</operation>
<item>employeeType</item>
</modification>
<modification>
<operation>modify</operation>
<item>organization</item>
</modification>
</policyConstraints>
<policyActions>
<certification>
<definitionRef oid="540940e9-4ac5-4340-ba85-fd7e8b5e6686" /> <!-- adhoc-certification -->
</certification>
</policyActions>
</policyRule>