지금 지원 담당자와 채팅
지원 담당자와 채팅

Identity Manager 9.2.1 - 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 Automatic attestation of policy violations
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 identity awaiting attestation Automatic acceptance of attestation approvals Phases of attestation Attestation by peer group analysis Approval recommendations for attestations Managing attestation cases
Attestation sequence Default attestations Mitigating controls Setting up attestation in a separate database Configuration parameters for attestation

Prevent attestation by identity awaiting attestation

The attestation object can also be determined as the attestor in an attestation case. which means the identities 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 identity option is set on an approval step, this configuration parameter has no effect.

To prevent identities from attesting themselves

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

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

  • Identities included in AttestationCase.ObjectKeyBase

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

  • Identities' main identities

  • All subidentities of these main identities

If the configuration parameter is not set or if the approval step has Approval by affected identity enabled, these identities can attest themselves.

Related topics

Automatic acceptance of attestation approvals

An attestor might be authorized to approve several levels of an approval workflow. By default, the attestation case is presented to them again at each approval level. To prevent this attestor from having to approve the attestation case several times, you can allow automatic approval. This passes on an approval decision that has been granted once already, to the next approval step irrespective of how any approval steps in between were approved.

NOTE: Automatic approvals apply to all fallback approvers but not to the chief approval team.

To attain automatic acceptance of an attestor's approval decisions in subsequent approval levels

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

    If the attestor has granted approval to the attestation case in a previous approval step, the approval is carried over. If the attestor has not granted approval to the attestation case in a previous approval step, the approval is presented to the approver again.

Related topics

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 identities 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 identities affected can be given the opportunity to challenge this decision. This allows attested identities 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.

    It is possible to challenge 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

Setting up the staging phase

A staging phase is when an approval level is inserted at the beginning of the approval workflow, which identifies the attestation policy owners as approvers. All attestation cases in an attestation run are thus submitted to a single identity (AttestationPolicy.UID_PersonOwner) or a group of identities (AttestationPolicy.UID_AERoleOwner) for review.

For example, a staging phase can be set up when the attestation policy or its components (attestation procedures, approval workflow, and so on) have been newly created and need to be tested to see if they deliver the expected results.

To set up a staging phase

  1. In the Manager, create a new approval workflow or edit an existing approval workflow.

  2. Add a new approval level at the beginning of the workflow and enter the approval step properties.

    • Approval procedure: PW - owner of the attestation policy.

  3. Drag the Approval connector from the decision level for testing to the next decision level.

  4. Save the changes.

  5. Assign an approval policy to the approval workflow.

  6. Assign an attestation policy to the approval policy.

  7. Assign a single owner or an application role as owner to the attestation policy.

  8. (Optional) Edit the main data of the attestation case assigned to attestation policy.

    • On the Template tab, in the Text template field, enter a text to describe the reviewers' and attestors' task.

      Example:

      For reviewer: Does the attestation case contain the correct data for the attestation object and will the correct attestors be identified?
      For attestors: Is the attestation object data correct and up-to-date?
  9. Save the changes.

This workflow configuration starts the attestation phase once the attestation policy owners has approved staging. If the approval step is denied, attestation for the current attestation case is finally denied and the necessary corrections can be made.

Detailed information about this topic
Related topics
관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택