Continuous Certification by Re-Approval

This chapter describes continuous certification via re-approval workflows. This is a highly effective method that distributes load with regard to your employees and your DirX Identity system and that works with maximum efficiency.

About this Use Case

This use case leverages DirX Identity’s re-approval feature. Privileges are flagged for re-approval and - depending on the timing conditions in place - a re-approval workflow is started for a specific assignment before the assignment’s end date is reached. 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 need to re-approve a specific assignment. They must decide whether the user keeps the privilege or whether the privilege should be removed.

The workflows are continuously started from a daily StartReapproval workflow. It checks for privilege assignments that are to be re-approved. To ensure that all assignments are correctly flagged, an InitializeReapproval workflow should be started in advance. The following figure illustrates the timing conditions.

Figure 2. Certification by Re-Approval Timing

In the figure:

The end date at the assignment marks the date where the next re-approval has to be finished. If this date is reached and the approval was accepted, the user keeps the assignment. If the approval was rejected or not performed in time, the user will lose the assignment at this date.
The next re-approval date is calculated from the current end date of the assignment plus the Re-approval Period value at the privilege (if this value is not available, the default value is taken from the domain object) or according to the Re-approval Date set at the privilege (if this value is not available, the default value is taken from the domain object). For a complete definition of the calculation, see the section "About Re-Approval" in Chapter 1.
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:

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 at which the re-approval must occur minus this approval period value. For example, if the re-approval is set to the end of May and you select a four-week period, the re-approval workflow is started at the beginning of May. If no approval period is configured at the domain, a default value of 14 days applies.
The Re-approval period is a default value that takes effect when the corresponding field at the privilege is not set. Typical values for re-approval periods are from three (3) months to two (2) years. The default value is three months.
Leave the Re-approval date empty because we want to run individual re-approvals for each assignment.

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 here. You can configure privileges of any other type if that is what’s required.

For each role requiring re-approval, set its Requires re-approval flag and then set the other parameters in one of the following ways:

If you want to have the same behavior for all privileges, leave the Re-approval date and Re-approval period empty. In this case, the domain settings apply.
If you have privileges requiring a shorter or longer re-approval period, set an individual Re-approval period at the privilege.

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.

Perform this procedure for all roles you want to be re-approved.

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 either manually if you changed the re-approval conditions at privileges or - and we recommend this method - regularly each night to be sure that all assignments are correctly set up for re-approval.

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.
With the flag updateConfiguredReapprovalDates in the General tab set, you can automatically shift the re-approval dates 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.
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.

Don’t forget to copy the rule and the workflow to be sure that changes in the configuration remain and are not overwritten by the next DirX Identity product update.

This workflow is set up as a separate workflow that runs exactly one consistency rule (InitializePrivilegeForReapproval). Alternatively, you can run it together with other consistency rules in your custom policy execution workflow.

StartReapproval

The StartReapproval workflow should run regularly once per night. It checks whether an assignment is flagged for re-approval and whether the end date is reached. 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.
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.

Don’t forget to 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 (StartWorkflowsForReapproval). Alternatively, you can run it together with other consistency rules in your custom policy execution workflow.

Running the Use Case

Run the configured workflows once and test the result. Be sure to run it in the sequence InitializeReapproval and then StartReapprovalWorkflows.

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.

If everything works well, set up schedules to run the two workflows regularly. We recommend that you set up a hierarchical workflow that defines the sequence and then run this workflow daily.

Alternative or Extended Configurations

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

Certifying Other Privilege Types

In this use case, we ran re-approval only on roles. If required, you also can run re-approval at 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.

Running Separate Campaigns

If you need to re-approve a huge number of privileges, think about setting up multiple workflows. Set up InitializeReapproval and StartReapprovalWorkflows workflows with different search bases and filters.

If you run separate campaigns, set up the corresponding schedules and try to distribute the load.