<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
This page shows you how to create ad-hoc certification campaigns. This can be useful in more specific cases, such as when a new user is added to an organization and its manager should review and certify all of the user’s assignments (roles, etc.).
Define Ad-hoc Certification Campaigns
To define an ad-hoc certification campaign:
-
Define a policy rule that triggers the creation of a new ad-hoc certification campaign.
-
Define the actual ad-hoc certification campaign.
Policy Rule
Policy rules can be configured to trigger a creation of a new ad-hoc certification campaign (not to be confused with the standard multi-object scheduled campaigns).
Such a rule looks like this:
There are two interesting items here:
-
A policy constraint (lines 3-5) applies 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 organizations for which we want to have ad-hoc certifications started for all newcomers.
-
Certification policy action (lines 8-10) that defines the certification campaign that should be started. More specifically,
definitionRef
points to the certification definition that specifies what the certification should look like; e.g. how many stages it should have, how to select reviewers for those stages, and so on.
Certification Campaign
See an example of an ad-hoc certification campaign below:
<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
.
In this case, it is not necessary because the scope is specified as a single-object definition, containing the object on which a particular certification policy action was triggered.
As scopeDefinition
is not defined, its objectType
and searchFilter
are replaced by the type of the current object, and a single-object OID-based filter, respectively.
There can be more certification policy actions, and each can contain multiple certification definition references to be started. Campaigns in midPoint are currently started independently. In the future, we may implement a composition mechanism, similar to the one used for approval policy actions.
The definition reference must be OID-based. Filter-based definitions (evaluated at run time) are not supported. |
Start certification after property change
You can use ad-hoc certification campaigns in a multitude of scenarios. In this section, you can see examples of starting an ad-hoc certification campaign when object items are modified:
<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>