Scheduled Certification by Re-Approval

This chapter describes scheduled certification via re-approval workflows. This is another use case that you can perform using the re-approval feature.

About this Use Case

This use case leverages DirX Identity’s re-approval feature. Privileges are flagged for re-approval and a central definition of the re-approval date is set at the domain. This use case defines a campaign that is run at the same time for all flagged privileges. The following figure illustrates this use case.

Figure 1. Certification by Re-Approval

The approvers of these workflows receive an e-mail notification informing them that they must re-approve a specific assignment. They need to decide whether the user keeps the privilege or whether the privilege shall be removed.

It makes sense to run the InitializeReapproval and StartReapproval workflows only once at the beginning of the campaign. This action starts all necessary workflows for the campaign. The following figure shows the timing condition details.

Figure 2. Certification by Re-Approval Timing

In the figure:

We assume that the Re-approval Date is only set at the domain, which means that it is used for all privilege assignments that are flagged for re-approval. All re-approval workflows are started at the same time. If the re-approval date is reached and the approval was accepted, the user keeps the assignment. If the approval was rejected or no decision was taken, the user will lose the assignment on this date.
We also assume that there is only a central definition of the Re-approval Period at the domain. This setting defines when the next re-approval will take place.
The timeout of the approval activity is individual per re-approval workflow. When this time expires, one or more escalations can occur depending on the workflow’s configuration.
The workflow has its own individual Workflow Timeout, which should be longer than the sum of all possible activity timeouts including the escalations.

Setup and Configuration

This use case requires you to set up the following items:

The relevant flags at the domain object
The re-approval properties at the privileges
The workflows

Setting up the Domain Object

Select the Domain Configuration view, click the top level node and then select the Timing tab.

In the Approval area, you should set three attributes that are relevant for re-approval:

The Reapproval period is a default value that takes effect when the corresponding fields at the privileges are not set. Because we want to run a certification campaign each year, we set the value to one (1) year. The default value is 3 months.
Because we intend to run a campaign at the end of March each year, we set the Reapproval date to the 31^st of March.
Set the Approval period to four (4) weeks to give the approvers enough time to react to the re-approval request. The re-approval workflow is started at the time when the re-approval must occur minus this approval period value. If the re-approval is set to end of March and you select a four-week period, the re-approval workflow is started at the beginning of March. If no approval period is configured at the domain, a default value of 14 days applies.

See the online help for an explanation of these settings.

Setting up the Privileges

To keep it simple, we only set up role re-approval for this use case. You can configure privileges of any other type if that is required.

Perform these steps for each privilege that requires re-approval:

Set the Requires re-approval flag.
If you want to use different re-approval workflows, set a link to the appropriate one in the Workflow field for each role. Make sure that the activity, escalation and workflow timeouts match the approval period.

All other parameters are taken from the domain definitions, so no further configuration is necessary.

Setting up the Workflows

You need to set up two workflows for re-approval. The next sections describe these tasks.

InitializeReapproval

The InitializeReapproval workflow sets, for all existing privilege assignments, whether an end date is set according to the defined conditions at the privilege and the domain object. You should run this workflow only once - in this case, at the beginning of March. The start of the workflow must be slightly later than the intended Re-approval date (31^st of March) minus the Approval period (4 weeks).

Open the workflow’s wizard in the Connectivity view group:

In the Rule Search Parameters tab, you can see that the InitializePrivilegeForReapproval consistency rule is run.
Check this rule in the Provisioning → Policies → Rules → Default → Consistency Rules → Reapproval folder. You can use the flag updateConfiguredReapprovalDates in the General tab to automatically shift the re-approval date that is configured at the domain: If the re-approval date lies in the past or within the approval period, it is shifted to the future by one re-approval period.
Check the filter conditions in the Filter tab. The Search Base works on the entire domain and the Search Filter is set to:
(dxrneedsreapproval="TRUE" and (objectclass="dxrRole" or objectclass="dxrPermission" or objectclass="dxrTargetSystemGroup"))
which means that it searches for all privileges that have the dxrNeedsReapproval flag set.

We recommend that you copy the rule and the workflow to be sure that changes in the configuration remain and are not overwritten by the next product update.

This workflow is set up as a separate workflow that runs exactly one consistency rule (InitializePrivilegeForReapproval). You could also run it with other consistency rules in your custom policy execution workflow.

StartReapproval

The StartReapproval workflow should run only once directly after the InitializeReapproval workflow. It checks whether an assignment is flagged for re-approval and whether the end date is reached, which is the case for all assignments. Then it starts the defined re-approval workflow.

Open the workflow’s wizard in the Connectivity view group:

In the Rule Search Parameters tab, you can see that the StartWorkflowsForReapproval consistency rule is run.
Check this rule in the Provisioning → Policies → Rules → Default → Consistency Rules → Reapproval folder. You can use the flag updateConfiguredReapprovalDates to automatically shift the re-approval date configured at the domain and/or the considered privileges: If the re-approval date lies in the past or within the approval period, it is shifted to the future by one re-approval period. Because the InitializeReapproval workflow performed this task, there is nothing to do.
Check the filter conditions in the Filter tab. The Search Base works on the entire domain and the Search Filter is set to:
(objectclass="dxrAssignment" and dxrneedsreapproval="TRUE"
and dxrEndDate<="$(approvaldate)" and (not (dxrInApproval="TRUE") or not (dxrInApproval=*)))
which means that it searches for all assignments that have the dxrNeedsReapproval flag set and whose end date is reached and where no re-approval workflow is already started.

We recommend that you copy the rule and the workflow to be sure that changes in the configuration remain and are not overwritten by the next product update.

Running the Use Case

Run the configured workflows at the defined time (the beginning of March). Be sure to run InitializeReapproval first and then run StartReapprovalWorkflows. We recommend that you build a combined workflow that starts both workflows in sequence.

After completion, view the status of the workflow and check the trace file for errors.

View the Request Workflow Monitor area to check for the newly created re-approval workflows.

Alternative or Extended Configurations

This section gives hints for alternative or extended configuration of this use case.

Certifying Other Privilege Types

In this use case, we only ran re-approval on roles. If required, you can also run re-approval at the permission or group level. Set the corresponding flags and fields at these types of privileges.

You can also run a certification on any mix of roles, permissions and groups.

Setting Individual Re-Approval Dates or Re-Approval Periods

You may want to set individual timing parameters for specific privileges.

For example, you could set an individual re-approval date at the privilege to perform re-approval on that date. If you do not set the re-approval period at the privilege, the value from the domain is taken.

You could also set the re-approval period at the privilege to enforce shorter or longer re-approval cycles.

If you set these individual parameters at the privileges, you should schedule the InitializeReapproval and StartReapproval workflows to run on a daily basis. Otherwise, re-approvals are set but the execution is not performed.