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

Identity Manager 9.0 LTS - 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 Attestation by peer group analysis Managing attestation cases
Attestation sequence Default attestation and withdrawal of entitlements User attestation and recertification Mitigating controls Setting up attestation in a separate database Configuration parameters for attestation

General main data for adaptive cards

Enter the following main data for an adaptive card.

Table 41: Adaptive card main data

Property

Description

Adaptive card

Name of the adaptive card.

Description

Text field for additional explanation.

Disabled

Specifies whether the adaptive card is actively used.

Adaptive card templates

Name of templates to use with this adaptive card.

Language

The template is provided in this language. The recipient's language preferences are taken into account when an adaptive card is generated and a matching template is applied. If a language cannot be identified or there is no suitable template for the language found, en-US is used as fallback.

Template

JSON template of the adaptive card that contains placeholders for Adaptive Cards Templating.

Related topics
  • Adaptive Karten erstellen, bearbeiten und löschen
  • Vorlagen für adaptive Karten erstellen, bearbeiten und löschen
  • Disabling adaptive cards

Deploying and evaluating adaptive cards for attestations

If an attestor is found in an approval step and this approval step has a mail template allocated to it, the ATT_AttestationHelper approve anywhere process is run. The process is generated if the following conditions are fulfilled:

  • The attestor is registered as the recipient in Starling Cloud Assistant.

  • A default email address is stored for the attestor.

  • The QER | Person | Starling | UseApprovalAnywhere configuration parameter is set.

  • An expiry date is entered in the QER | Person | Starling | UseApprovalAnywhere | SecondsToExpire configuration parameter.

  • The QER | Attestation | MailTemplateIdents | RequestApproverByCollection configuration parameter is not set.

    - OR -

    Always send notification of pending attestations is set on the attestation policy.

The process calls the ATT_CloudAssistant_CreateMessage_AttestationHelper script passing to it the name and UID of the adaptive card to send. The script creates the adaptive card from the JSON template for adaptive cards and the data in the attestation case and then sends it to the attestor. The QER_CloudAssistant_CheckMessage_AttestationHelper script checks if the attestor has sent a response, evaluates the response and updates the attestation case according to the approval decision.

NOTE: If you want to use your own adaptive cards template, check the ATT_CloudAssistant_CreateMessage_AttestationHelper, ATT_CloudAssistant_CreateData_AttestationHelper, and ATT_CloudAssistant_CheckMessage_AttestationHelper scripts and adjust them if necessary to reflect content changes in the template. For more information about overriding scripts, see the One Identity Manager Configuration Guide.

Related topics

Disabling adaptive cards

Adaptive cards that are not used can be disabled.

To disable an adaptive card

  1. In the Manager, select the Attestation > Basic configuration data > Adaptive cards category.

  2. Select the adaptive card in the result list.

  3. Select the Change main data task.

  4. Set Disabled.

  5. Save the changes.
Related topics

Default attestation and withdrawal of entitlements

One Identity Manager provide various default attestation procedures for different data situations and default attestation procedures.

Data situations for default attestations:

  • System entitlements owned by an employee

  • System entitlements assigned to system entitlements

  • System entitlements assigned to hierarchical roles

  • System roles assigned to an employee

  • Company resources assigned to system roles

  • System roles assigned to hierarchical roles

  • Business and application role memberships

  • Employee main data of a new One Identity Manager user

  • Employee main data of an existing One Identity Manager user

The attestation polices required for attesting employee main data are also supplied by default. You can also use the default supplied attestation policies without modifying them. The prerequisites and the attestation sequence for employee data are described in User attestation and recertification.

You can set up attestation policies easily in the Web Portal using default attestation procedures for other data situations. You can also use the default attestation policies supplied without customizing them. Furthermore, you can configure how to deal with denied attestations that are based on these default attestation procedures. If your specific data situation allows, denied entitlements can be removed by One Identity Manager following the attestation.

To remove denied permissions automatically

  1. In the Designer, set the QER | Attestation | AutoRemovalScope configuration parameter and the configuration subparameters.

  2. If the entitlements were obtained through IT Shop, specify whether these requests should be unsubscribed or canceled. To do this, set the QER | Attestation | AutoRemovalScope | PWOMethodName configuration parameter and select a value.

    • Abort: Requests are canceled. In this case, they do not go through a cancellation workflow. The requested entitlements are withdrawn without additional checks.

    • Unsubscribe: Requests are unsubscribed. They go through the cancellation workflow defined in the approval policies. Withdrawal of the entitlement can thus be subjected to an additional check.

      If the cancellation is denied, the entitlement is not withdrawn even though the attestation has been denied.

    If the configuration parameter is not set, the requests are canceled.

IMPORTANT: If role memberships or system roles are removed from an employee they lose the unapproved entitlement. They also lose all other company resources inherited through this role. These may be other system entitlements or account definitions. If necessary, system entitlements are removed and company resources are deleted from the employee.

Check whether your data situation allows automatic withdrawal of entitlements before you enable configuration parameters under QER | Attestation | AutoRemovalScope.

Automatic removal of entitlements is triggered by an additional approval step with the EX approval procedure in the default approval workflows.

Attestation sequence with subsequence withdrawal of denied entitlements:

  1. Attestation is carried out using a default attestation procedure.

  2. The attestor denies attestation. The approval step is not granted approval and approval is passed on the next approval level with the EX approval procedure.

  3. The approval step triggers the AUTOREMOVE event. This runs the VI_Attestation_AttestationCase_AutoRemoveMembership process.

  4. The process runs the VI_AttestationCase_RemoveMembership script. This removes the affected entitlement depending on which configuration parameters are set.

  5. The script sets the approval step status to Denied. This means the entire attestation case is finally denied.

  6. Tasks to recalculate inheritance are entered in the DBQueue.

Detailed information about this topic
관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택