立即与支持人员聊天
与支持团队交流

Identity Manager On Demand - Starling Edition Hosted - 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

Criteria for the Staging phase

In the staging phase, at the beginning of each attestation run of the attestation policy, the generated attestation cases are checked for correctness. Staging criteria can be:

  • Attestation scope

    Will too many or too few attestation cases be created?

    -> Does the condition of the attestation policy need to be worded differently?

  • Attestation sequence

    Will the correct attestors be identified in the correct order?

    -> Must the application workflow be changed?

  • Details of the attestation objects that the attestors see

    • Is too much or too little detailed information displayed?

      -> Does the report on attestation procedure or the content of the snapshot need to be changed?

    • Is incorrect information shown?

      -> Must the attestation object's main data need to be corrected?

If errors are found only in individual attestation cases, you can deny these attestations and make the necessary corrections to the attestation objects. All other attestation cases can be approved and continue down the approval process.

If fundamental issues are found with the attestation policy, the attestation procedure, or the approval workflow used, you can flag all pending attestation procedures, deny them all together, and then make the necessary corrections.

Related topics

Setting up the challenge phase

If an attestation is finally denied, the identities affected can be given the opportunity to challenge this decision. The challenge may be particularly useful if entitlements are to be automatically withdrawn following denied attestations. Those affected can prevent this in the final instance.

To set up the challenge phase

  1. In the Manager, edit an approval workflow and add a new approval level at the end of the workflow.

  2. Enter the approval step properties.

    • Approval procedure: CN - Challenge the decision

    If the workflow includes an approval level for automatically withdrawing attested entitlements , the challenge approval level must be inserted directly before it.

  3. Drag the Deny connector from the previous approval level to the challenge approval level.

  4. (Optional) Drag the Deny connector from the challenge approval level to the approval level for automatically withdrawing entitlements .

  5. Save the changes.

  6. Assign an approval policy to the approval workflow.

  7. Assign an attestation policy to the approval policy.

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

  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 attestors task.

  9. Save the changes.

If those affected deny this approval step, the attestation is finally denied approval. If automatic withdrawal of entitlements is configured, the attested assignment is then automatically removed. If those affected approve this approval step, the attestation is finally granted approval.

Detailed information about this topic
Related topics

Setting up withdrawal of 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.

To setup automatic withdrawal of entitlements

  1. In the Manager, edit an approval workflow and add a new approval level at the end of the workflow.

  2. Enter the approval step properties.

    • Approval procedure: EX - Approvals to be made externally

    • Event: AUTOREMOVE

  3. Drag the Deny connector from the previous approval level to the approval level for automatically withdrawing entitlements.

  4. Save the changes.

  5. Assign an approval policy to the approval workflow.

  6. Assign an attestation policy to the approval policy.

    Automatic withdrawal of entitlements is possible if attesting memberships or assignments to application roles, business role, system roles, or system entitlements.

  7. Save the changes.

  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.

Detailed information about this topic
Related topics

Attestation by peer group analysis

Using peer group analysis, approval for attestation cases can be granted or denied automatically. For example, a peer group might be all identities in the same department. Peer group analysis assumes that these identities require the same system entitlements or secondary memberships. For example, if the majority of identities belonging to a department have a specific system entitlement, assignment to another identity in the department can be approved automatically. This helps to accelerate approval processes.

Peer group analysis can be used during attestation of the following assignments or memberships:

  • Assignments of system entitlements to user accounts ( UNSAccountInUNSGroup table) if the user account is linked to an identity
  • Secondary memberships in roles and organizations (PersonInBaseTree table and its derivatives)

Peer groups contain all identities with the same manager or belonging to the same primary or secondary department as the identity linked to the attestation object (= identity to be attested). Configuration parameters specify which identity belong to the peer group. At least one of the following configuration parameters must be set.

  • QER | Attestation | PeerGroupAnalysis | IncludeManager: Identities with the same manager as the identity being attested

  • QER | Attestation | PeerGroupAnalysis | IncludePrimaryDepartment: Identities that belong to the same primary department as the identity being attested

  • QER | Attestation | PeerGroupAnalysis | IncludeSecondaryDepartment: Identities whose secondary department corresponds to the primary or secondary department of the identity being attested

The number of identities in a peer group that must already own the assignment or membership to be attested is set by a threshold in the QER | Attestation | PeerGroupAnalysis | ApprovalThreshold configuration parameter. The threshold specifies the ratio of the total number of identities in the peer group to the number of identities in the peer group who already own this assignment or membership.

You can also specify that identities are not permitted to own cross-functional assignments or memberships, which means, if the assignment or membership and the identity being attested belong to different functional areas, the attestation case should be denied approval. To include this check in peer group analysis, set the QER | Attestation | PeerGroupAnalysis | CheckCrossfunctionalAssignment configuration parameter.

Whether an assignment or a membership is cross-functional or not can only be verified if the following conditions are fulfilled:

  • The identity being attested and the member of the peer group requested the assignment or membership in the IT Shop.

  • The identity being attested is assigned to a primary department and this department is assigned to a functional area.

  • The service item to which the assignment or membership is assigned, is assigned to a functional area.

Attestation cases are automatically approved for fully configured peer group analysis, if both:

  • The membership being attested is not cross-functional

  • The number of identities in the peer group who already own this membership equal or exceeds the given threshold

If this is not the case, attestation cases are automatically denied.

To use this functionality, One Identity Manager provides the QER_PersonWantsOrg_Peer group analysis process and the PeergroupAnalysis event. The process is run using an approval step with the EX approval procedure.

Detailed information about this topic
相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级