Ad-Hoc Certification

Last modified 18 Aug 2025 13:29 +02:00

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:

  1. Define a policy rule that triggers the creation of a new ad-hoc certification campaign.

  2. 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:

Policy rule action triggering an ad-hoc certification
<policyRule>
  <policyConstraints>
    <assignment>
      <operation>add</operation>
    </assignment>
  </policyConstraints>
  <policyActions>
    <certification>
      <definitionRef oid="540940e9-4ac5-4340-ba85-fd7e8b5e6686" /> <!-- adhoc-certification -->
    </certification>
  </policyActions>
</policyRule>

There are two interesting items here:

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

  2. 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:

Ad-hoc certification campaign 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. 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:

Ad-hoc certification when both employeeType and organization 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>
Ad-hoc certification when employeeType and/or organization are changed
<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>
Was this page helpful?
YES NO
Thanks for your feedback