Navigation Tree

Ad-hoc certification

Last modified 30 Sep 2026 14:25 UTC

Micro-certification feature

This page describes Micro-certification midPoint feature. Please see the feature page for more details.

Table of Contents

Define ad-hoc certification campaigns
- Policy rule
- Certification campaign
Start certification after property change

This guide shows how to create ad-hoc certification campaigns.

Ad-hoc certification campaigns are useful for situations that need to be taken care of right away, rather than waiting for the next scheduled regular certification campaign. For example, when an employee changes a department, they are unassigned from one organization unit in midPoint and assigned to another. The organization units may contain policies giving users accesses appropriate for the particular unit. These accesses are granted and revoked automatically when users move across the units, no further action needed.

However, any manually assigned roles the user may have requested remain untouched. Those may have been relevant for the employee’s previous job assignment, but are they still relevant after the move? The ad-hoc certification campaign is triggered to have that reviewed and certified by a human reviewer.

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

Certification template vs. instance

An ad-hoc certification campaign template may be defined for multiple objects and targets, same as the standard campaign template can, but every instance of an ad-hoc certification campaign is always single-object and single-target, unlike the standard 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 points of interest 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:

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>

Compliance

This feature is related to the following compliance frameworks:

Was this page helpful?

YES NO

Thanks for your feedback