Configuring Certification Campaign Stages
This page describes how to configure individual stages within an access certification campaign. It covers the reviewer selection, deadlines, notification behavior, and timed escalation within each stage.
Also, it explains how midPoint determines and assigns reviewers based on properties such as role owner, approver, or organizational manager, and shows how these are defined in XML under <stageDefinition> elements.
Configure stages
Campaigns consist of one or more review stages.
In GUI, you can configure individual stages in Certification > Campaign definitions > your definition > Stages definition tab.
You can configure the following options for stages:
-
Name - The name of the stage.
-
Description - Description of the stage.
-
Duration - Duration of the stage which is used to determine the end of the stage. See stage duration for details.
-
Notify before deadline - Defines how long before the stage end time a notification is sent. See deadline notifications for details.
-
Notify only when no decision - If selected, notifications are sent to reviewers only if they have cases waiting for their decision. See no decision notifications.
-
Reviewer specification name (optional) - Identifies the reviewer-selection rules configured for the stage.
-
Reviewer specification description (optional) - Describes the reviewer-selection rules configured for the stage.
-
Reviewers based on assignment target object - Selects reviewers based on the target owner/approver of the assignment/inducement. For example, you can define that a role owner certifies all assignments of their role.
-
Reviewers based on the object being assigned to - Selects reviewers based on objects to which something is assigned or induced. For example, you can define that a role owner certifies all inducements to their role.
-
Reviewers based on the manager of object being assigned to - Selects reviewers based on managers of object that have something assigned or induced. For example, you can have a manager certify all assignments to users in their organization.
-
Default reviewer reference - Defines the default reviewers that are used if the preceding configuration does not result in actual reviewers. For example, if you define that a user’s manager is the reviewer for that user’s assignments, and if that particular user has no managers, the default reviewers will be used to review the assignments of that user.
-
Additional reviewer reference - Defines additional reviewers that are used on top of the other reviewers defined in the preceding configuration. For example, you can specify that the company security manager should review each certification case in the given stage.
-
Decision aggregation strategy in case of more than one reviewer - If there is more than one reviewer, defines the strategy used to determine the stage-level outcome. See stage level strategies for details.
-
Outcome if there are no reviewers allocated - Defines the outcome for cases if no reviewers are assigned, for example, if the target role owner is defined as the reviewer but that particular role has no owner. Note that this does not apply to cases when the assigned reviewers provide no responses.
-
Stop review on - Defines which outcomes prevent cases to be advanced to the next stage. Typically, if a case is marked as Revoke or Reduce, it does not proceed to the next stage. This is typically not needed, and can only be configured in the XML configuration. For more details, see Determining Certification Case Outcome.
Configuration details
Stage duration
The duration is used to determine the stage end time. The end time is computed as the moment of the stage opening plus the duration, rounded up to 23:59:59 of the last day. So, for example, if the stage is started on Monday, April 25th at 13:45, and the duration is 7 days, the stage would end on Monday, May 2nd at 23:59:59.
The duration is specified in the ISO 8601 format.
See the following examples:
| Value | Explanation |
|---|---|
P14D |
14 days |
P3W |
3 weeks |
P2M |
2 months |
P2M3D |
2 months and 3 days |
Deadline notifications
There are two kinds of notifications that are sent when the stage end is approaching:
-
Notifications for the campaign owner
-
Notifications for reviewers
Both of these notifications are sent before the stage end time, in intervals defined by the notifyBeforeDeadline multi-valued property.
For example, if the notifyBeforeDeadline property is set to 48 and 12 hours, and the stage ends on Monday, May 2nd at 23:59:59:
-
The first round of notifications (to campaign owner and individual reviewers) will be sent on Saturday, April 30th 23:59:59 (48 hours before the stage end).
-
The second round of notifications (to campaign owner and individual reviewers) will be sent on Monday, May 2nd, 11:59:59 (12 hours before the stage end).
For more information, see Access Certification Notifications.
No decision notifications
You can set up deadline notifications to be sent only when reviewers have cases they have not responded to yet.
This is done by setting the notifyOnlyWhenNoDecision property to true (default).
If you set the property to false, reviewers always get their notifications - regardless of whether they have provided a response or not.
| Regardless of this setting, deadline notifications are always sent to the campaign owner. |
For more information, see Access Certification Notifications.
Reviewer selection
Each review stage starts with selecting reviewers for each certification case that enters that stage.
When considering assignment-based certifications, reviewers can be selected either according to the:
Assignment target properties
Imagine that we are going to certify the assignment of the Superuser role to user jack. The target of this assignment is the Superuser role.
MidPoint supports two properties of a role (or an org/service) that can be used to derive reviewers:
-
useTargetOwner- For role/org/service/resource owners. -
useTargetApprover- For role/org/service/resource approvers.
You can use either one (or both) as reviewers for assignments by setting useTargetOwner and/or useTargetApprover to true.
Assignment owner properties
The assignment owner is the object (usually a user) to which we are assigning another object. In the example above, the owner of the assignment is the user jack.
MidPoint supports the following properties of the assignment owner that can be used to find reviewers:
-
role/org/service owner,
-
role/org/service approvers,
-
user/role/org/service managers.
Managers
In midPoint, each object can belong to one or more organizations (orgs). Each org can have zero or more managers, and zero or more parent orgs. So it is quite natural to define the term "manager(s) of an object X" as the manager(s) of the org(s) that X belongs to.
When determining managers for a given object, two parameters can be helpful:
-
Limitation of org types that should be taken into account.
-
Flag that defines whether to allow users to act as their own managers.
To better understand these two parameters, let’s have a look at the process of determining managers of an object X.
In the first round, we take managers of all org units that X belongs to. Optionally, we filter out the following:
-
If a limitation of org types is set, we filter out all orgs whose org type is not equal to the specified type.
-
If the flag that allows users to act as their own managers is
false(default), we do not consider X to be the manager of X, even if X is the manager of the corresponding org unit.
If we find at least one suitable manager, we are done. Otherwise, we continue the process, taking all found orgs (of a suitable type, if specified), and continue by looking for managers of their parents (again, of suitable types).
Example
The following example is taken from the Monkey island midPoint sample:
We have the following two structures:
-
Functional structure - The root is Governor Office, managed by Elaine Marley:
-
Ministry of Defense, has no manager
-
Ministry of Offense, has no manager
-
Swashbuckler Section, has no manager
-
Scumm Bar, managed by Ignatius Cheese
-
-
Ministry of Rum, managed by Guybrush Threepwood
-
Scumm Bar, managed by Ignatius Cheese
-
-
-
Project structure - The root is Projects:
-
Save Elaine, has no manager,
-
Kidnap and marry Elaine, managed by Captain LeChuck.
-
Now, let’s find managers for the user Guybrush. He is a member of Scumm Bar and manager of Ministry of Rum (let’s assume he is also a member of Ministry of Rum, although this is not part of the Monkey island example). So, when looking for his managers, two organizations are taken into account: Scumm Bar and Ministry of Rum. This means that the managers are: Ignatius Cheese and Guybrush himself (if allowSelf is set to true). If allowSelf is kept at the default value of false, the only manager of Guybrush is Ignatius Cheese. If we limited the org type to "project", Guybrush would have no managers.
As a second example, let’s find managers of Carla the Swordmaster, a member of Ministry of Defense, Ministry of Rum, and Save Elaine. Among these three orgs, only Ministry of Rum has a direct manager. So Carla’s manager is Guybrush Threepwood. If Carla was only a member of Ministry of Defense, her manager would be Elaine Marley.
Finally, let’s find managers for Bob, who is a member of the Kidnap and marry Elaine project. In the default setting, his manager is Captain LeChuck. If we restricted org types to functional only, Bob would have no managers.