Tchater maintenant avec le support
Tchattez avec un ingénieur du support

Identity Manager 9.1.2 - Attestation Administration Guide

Attestation and recertification
One Identity Manager users for attestation Attestation base data Attestation types Attestation procedure Attestation schedules Compliance frameworks Chief approval team Attestation policy owners Standard reasons for attestation Attestation policies Sample attestation Grouping attestation policies Custom mail templates for notifications Suspending attestation
Approval processes for attestation cases
Approval policies for attestations Approval workflow for attestations Selecting attestors Setting up multi-factor authentication for attestation Prevent attestation by employee awaiting attestation Phases of attestation Attestation by peer group analysis Managing attestation cases
Attestation sequence Default attestation and withdrawal of entitlements User attestation and recertification Certifying new roles and organizations Mitigating controls Setting up attestation in a separate database Configuration parameters for attestation

Determining the responsible attestors

The DBQueue Processor calculates which employee is authorized as an approver and in which approval level. Once an attestation is triggered, the attestors are determined for every approval step of the workflow to be processed. Changes to responsibilities may lead to an employee no longer being authorized as an approver for an attestation that is not yet finally approved. In this case, the attestors must be recalculated. The following changes can trigger recalculation of pending attestations:

  • Approval policy, workflow, step, or procedure changes.

  • An authorized approver loses their responsibility in One Identity Manager, for example, if a change is made to the department manager, attestation policy approver, or target system manager.

  • An employee obtains responsibilities in One Identity Manager and therefore is authorized as an approver, for example as the manager of the employee to be attested.

  • An employee authorized as an approver is deactivated.

Once an employee's responsibilities have changed in One Identity Manager, a task for recalculating the attestors is queued in the DBQueue. All approval steps of the pending attestation cases are also recalculated by default. Approval steps that have already been approved remain approved, even if their attestor has changed. Recalculating attestors may take a long time depending on the configuration of the system environment and the amount of data to be processed. To optimize this processing time, you can specify the approval steps for which the attestors are to be recalculated.

NOTE: The task for recalculating the attestor for the approval step is added to the queue by default approval procedures. Approval steps with custom defined approval procedures are not recalculated automatically.

To configure recalculation of the attestors

  • In the Designer, set the QER | Attestation | ReducedApproverCalculation configuration parameter and select one of the following options as the value.

    Table 32: Options for recalculating attestors
    Option Description

    No

    All approval steps are recalculated. This behavior also applies if the configuration parameter is not set.

    Advantage: All valid attestors are displayed in the approval process. The rest of the approval sequence is transparent.

    Disadvantage: Recalculating attestors may take a long time.

    CurrentLevel

    Only the attestors for the approval level that is currently to be edited are recalculated. Once an approval level has been approved, the attestors are determined for the next approval level.

    Advantage: The number of approval levels to calculate is lower. Calculating the attestors may be faster.

    TIP: Use this option if performance problems occur in your environment in connection with the recalculation of attestors.

    Disadvantage: The originally calculated attestors are still displayed in the approval sequence for each subsequent approval step, even though they may no longer have approval authorization. The rest of the approval sequence is not correctly represented.

    NoRecalc

    No recalculation of attestors. The previous attestors remain authorized to approve the current approval level. Once an approval level has been approved, the attestors are determined for the next approval level.

    Advantage: The number of approval levels to calculate is lower. Calculating the attestors may be faster.

    TIP: Use this option if performance problems occur in your environment in connection with the recalculation of attestors, even though the CurrentLevel option is used.

    Disadvantage: The originally calculated attestors are still displayed in the approval sequence for each subsequent approval step, even though they may no longer have approval authorization. The rest of the approval sequence is not correctly represented. Employees that are no longer authorized can approve the current approval level.

    In the worst-case scenario, the only attestors originally calculated here now have no access to One Identity Manager, for example, because they have left the company. The approval level cannot be approved.

    To see approval steps of this type through

    • Define a timeout and timeout behavior when you set up the approval workflows on the approval steps.

      - OR -

    • When setting up the attestation, assign members to the chief approval team. These members can access pending attestation cases at any time.

Detailed information about this topic
Related topics

Setting up multi-factor authentication for attestation

You can set up additional authentication for particularly security critical attestations, which requires every attestor to additionally authenticate themselves for attestation. In your attestation policies, define which attestation policies require this authentication.

One Identity Manager uses OneLogin for multi-factor authentication. Usable authentication modes are determined through the OneLogin user accounts linked to the employees.

Prerequisites

In OneLogin:

  • At least one authentication method is configured on all user accounts that are going to use multi-factor authentication.

In One Identity Manager:

  • The OneLogin Module is installed.

  • Synchronization with a OneLogin domain is set up and has been run at least once.

  • Employees linked to OneLogin user accounts.

  • The API Server and the web application are configured as required.

For more information about setting up multi-factor authentication, see the One Identity Manager Authorization and Authentication Guide.

To use multi-factor authentication for attesting

  1. In the Manager, select the attestation policies to which you want to apply multi-factor authentication.

  2. Enable the Approval by multi-factor authentication option.

    Multi-factor authentication cannot be used for default attestation policies.

Once the Approval by multi-factor authentication option is enabled on an attestation policy, additional authentication is requested in each approval step of the approval process. Attestors can select any one of the authentication methods assigned to their OneLogin user accounts.

IMPORTANT: An attestation cannot be sent by email if multi-factor authentication is configured for the attestation policy. Attestation emails for such attestations produce an error message.

For more information about multi-factor authentication, see the One Identity Manager Web Portal User Guide.

Related topics

Prevent attestation by employee awaiting attestation

The attestation object can also be determined as the attestor in an attestation case. which means the employees to be attested can attest themselves. To prevent this, set the QER | Attestation | PersonToAttestNoDecide configuration parameter.

NOTE:

  • Changing the configuration parameter only affects new attestation cases. Attestors are not recalculated for existing attestation cases.

  • The configuration parameter setting also applies for fallback approvers; it does not apply to the chief approval team.

  • If the Approval by affected employee option is set on an approval step, this configuration parameter has no effect.

To prevent employees from attesting themselves

  • In the Designer, set the QER | Attestation | PersonToAttestNoDecide configuration parameter.

This configuration parameter affects all attestation cases in which employees included in the attestation object or in object relations, are attestors at the same time. The following employees are removed from the group of attestors.

  • Employees included in AttestationCase.ObjectKeyBase

  • Employees included in AttestationCase.UID_ObjectKey1, ObjectKey2, or ObjectKey3

  • Employees' main identities

  • All subidentities of these main identities

If the configuration parameter is not set or if Approval by affected employee is enabled for the approval step, these employees can attest themselves.

Related topics

Properties of an approval step

Phases of attestation

When performing attestations, it can be helpful to check in advance that the correct attestation objects are generated and the appropriate approvers are found. This determines whether the approval process can be deployed as defined and used for attestation or if it requires customizing. A staging phase like this can be added to the beginning of the approval procedure.

If entitlements are withdrawn because attestation was denied, affected employees can be given the opportunity to challenge the denial and thereby prevent the entitlements being withdrawn. A challenge phase like this can be placed at the end of the approval procedure. Depending on the outcome of the challenge, entitlements can subsequently be withdrawn automatically or manually.

Thus, approval procedures can be divided into four phases:

  1. (Optional) Staging

    Those responsible for attestations, specifically the owners of the respective attestation policy, are given the opportunity here to review the details of an attestation run. This allows the scope and sequence of attestation to be assessed before attestation is carried out. If errors are detected in the generated attestation cases, the affected attestation cases can be canceled, the errors corrected, and attestation restarted.

    The staging phase can be integrated into the approval processes of any attestation objects.

  2. Attestation

    Attestation is run according to the defined approval workflow.

  3. (Optional) Challenge

    If an attestation is finally denied, the employees affected can be given the opportunity to challenge this decision. This allows attested employees to register their legitimate interests before entitlements are withdrawn. For example, this prevents entitlements that are needed at short notice from being withdrawn by a scheduled attestation and then having to reassign them again with additional effort.

    A challenge is possible if attesting user accounts, memberships in roles and organizations, or memberships in system entitlements.

  4. (Optional) Automatically withdraw entitlements

    If an attestation is denied in the end, the denied entitlements can be removed immediately. To do this, an automatic approval step with external approval is added to the end of the approval workflow.

For all four phases, appropriate approval levels are defined in the approval workflows.

Detailed information about this topic
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation