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

Identity Manager 9.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 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

Configuring peer group analysis for attestations

To configure peer groups

  1. In the Designer, set the QER | ITShop | PeerGroupAnalysis configuration parameter.

  2. Set at least on of the following subparameters:

    • QER | Attestation | PeerGroupAnalysis | IncludeManager: Identities with the same manager as the identity linked to the attestation object.

    • QER | Attestation | PeerGroupAnalysis | IncludePrimaryDepartment: Identities that belong to the same primary department as the identity linked to the attestation object.

    • QER | Attestation | PeerGroupAnalysis | IncludeSecondaryDepartment: Identities whose secondary department corresponds to the primary or secondary department of the identity linked to the attestation object.

    This allows you to specify which identities belong to the peer group. You can also set two or all of the configuration parameters.

  3. To specify a threshold for the peer group, set the QER | Attestation | PeerGroupAnalysis | ApprovalThreshold configuration parameter and specify a value between 0 and 1.

    The default value is 0.9. That means, at least 90 percent of the peer group members must already have the membership to be attested in order for the attestation case to be approved.

  4. (Optional) To check whether the membership to be attested is cross-functional, enable the QER | Attestation | PeerGroupAnalysis | CheckCrossfunctionalAssignment configuration parameter.

    • Ensure that the following conditions are met:

      • 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.

      Only functional areas that are primary assigned service items are taken into account.

      For more information about editing service items, see the One Identity Manager IT Shop Administration Guide. For more information about functional areas, see the One Identity Manager Identity Management Base Module Administration Guide.

  5. In the Manager, create an approval workflow with at least one approval level. For the approval step, enter at least the following data:

    • Single step: EXWithPeerGroupAnalysis.

    • Approval procedure: EX

    • Event: PeerGroupAnalysis

    The event starts the ATT_AttestationCase_Peer group analysis process, which runs the ATT_PeerGroupAnalysis_for_Attestation script.

    The script runs automatic approval and sets the approval step type to Grant or Deny.

Detailed information about this topic
Related topics

Approval recommendations for attestations

A way to accelerate the approval process by making automatic attestation approval decisions, is with approval recommendations. This process uses different criteria to determine whether attestation is more likely to be granted or denied approval. Based on the recommendation, attestations can be automatically granted approval. If denying approval is recommended or a clear recommendation cannot be made, the attestations must be submitted to additional attestors. These attestors are shown the approval recommendation and the recommendation details so that they can use this information to make an approval decision.

Detailed information about this topic

Criteria for approval recommendations for attestation

Various criteria are evaluated for approval recommendations. Which criteria can be applied depends on the object to be attested. For example, the last time a user account logged in to the target system can only be evaluated when attesting user accounts or assigning user accounts to system entitlements. This criterion is not applicable to other attestation objects. Non-applicable criteria do not affect the outcome of the recommendation.

The following criteria are evaluated when determining recommendations for approving attestation cases.

  1. Peer group factor

    The peer group factor assumes that all members of a peer group require the same system entitlements or secondary memberships. For example, if the majority of identities belonging to a department have a certain system entitlement, assignment to another identity in the department can be approved.

    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 | Recommendation | PeerGroupThreshold 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.

    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

    This criterion is evaluated only for the following attestations:

    • 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)
  2. Assigned functional area

    This evaluates whether the assignment to attest and the primary department of the identity to attest are assigned to the same functional area. If this is not the case, the assignment or membership is considered cross-functional. 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.

    This criterion is evaluated only for the following attestations:

    • 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)
  3. Compliance rule violations

    This evaluates whether the attestation object may violate existing compliance rules if the attestation were granted approval. Once a rule violation is detected, denying the attestation is recommended.

    This criterion is evaluated for all attestation objects.

  4. Risk factor

    This calculates the risk factor of the attestation object. If this risk index exceeds the specified threshold, denying approval is recommended. The threshold is specified in the QER | Attestation | Recommendation | RiskIndexThreshold configuration parameter.

    This criterion is evaluated for all attestation objects that have a risk index ( RiskIndex or RiskIndexCalculated column).

  5. Approval rate

    This determines the proportion of approvals for this attestation object in previous attestations. For this, all approval procedures with manual approval that are also used in the currently running approval workflow are determined in the approval sequence (AttestationHistory). The proportion of approvals for the same attestation object is determined from the entries in the approval sequence.

    If the approval rate exceeds the specified threshold, granting approval is recommended. The threshold is specified in the QER | Attestation | Recommendation | ApprovalRateThreshold configuration parameter.

    This criterion is evaluated for all attestation objects that were already attested.

  6. Assignment rate

    This determines the number of company resource assignments to the attested identity (PersonHasObject) and compares it to the average number per identity. If the assignment rate is less that the average per identity, denying approval is recommended.

    This criterion is evaluated only when identities are being attested (Person table).

  7. Last log in time

    This determines the last time the user account logged in (from UNSAccount.LastLogon). If the login was more that a defined number of days in the past, denying approval is recommended. The number of days is set in the QER | Attestation | Recommendation | UnusedDaysThreshold configuration parameter.

    This criterion is evaluated only when attesting user accounts (such as the UNSAccount table) or system entitlement assignments to user accounts (UNSAccountInUNSGroup table) if the LastLogin column exists in the user account table.

Recommendation for granting approval

All applicable criteria are fulfilled. That means:

  • The peer group has members and the peer group factor is higher than the threshold (PeerGroupThreshold).

  • The attestation object and the primary department of the attested identity belong to the same functional area. Therefore the attestation object is not cross-functional.

  • There are not rule violations.

  • The risk index of the attestation object is lower than the threshold (RiskIndexThreshold).

  • The approval rate is higher than the threshold (ApprovalRateThreshold).

  • The assignment rate is higher than average.

  • The last login was less than the specified number of days ago (UnusedDaysThreshold) and a time for the last login is entered.

Recommendation for denying approval

At least one of the following criteria applies.

  • The peer group has no members or the peer group factor is lower than the threshold (PeerGroupThreshold).

  • There is at least one rule violation.

  • The assignment rate is less than average.

If at least two of the following applicable criteria hold, denying approval is also recommended.

  • The product is cross-functional.

  • The risk index of the attestation object is higher than the threshold (RiskIndexThreshold).

  • The approval rate is lower than the threshold (ApprovalRateThreshold).

  • The last login was longer than the specified number of days ago (UnusedDaysThreshold) or there is no time entered for the last login.

In all other cases, no recommendation is given.

Related topics

Configuring approval recommendations for attestation

To use approval recommendations, add an additional approval level to the approval workflows and configure the thresholds. Based on the recommendation, attestations can be automatically granted approval. If denying approval is recommended or a clear recommendation cannot be made, the attestations must be submitted to additional attestors. If requests are not approved automatically, also define a manual approval level in case the recommendation is to grant approval.

The attestors are shown the approval recommendation. They can follow the recommendation or make their own approval decision independently.

TIP: One Identity Manager provides the Attestation by the identity's manager (with approval recommendation) sample workflow for approval recommendations with automatic approval. You can use this approval workflow as a template and adjust to suit your requirements. To do this, copy the workflow and add approval levels with manual approval steps.

To configure approval recommendations

  1. In the Designer, set the QER | ITShop | PeerGroupAnalysis configuration parameter.

  2. Set at least on of the following subparameters:

    • QER | Attestation | PeerGroupAnalysis | IncludeManager: Identities with the same manager as the identity linked to the attestation object.

    • QER | Attestation | PeerGroupAnalysis | IncludePrimaryDepartment: Identities that belong to the same primary department as the identity linked to the attestation object.

    • QER | Attestation | PeerGroupAnalysis | IncludeSecondaryDepartment: Identities whose secondary department corresponds to the primary or secondary department of the identity linked to the attestation object.

    This allows you to specify which identities belong to the peer group. You can also set two or all of the configuration parameters.

  3. Specify the threshold for the peer group factor in the QER | Attestation | Recommendation | PeerGroupThreshold configuration parameter. Enter a value between 0 and 1.

    The default value is 0.9. That means, at least 90 percent of the peer group members must already have the attestation object so that the granting approval can be recommended.

  4. Set the threshold for the risk factor in the QER | Attestation | Recommendation | RiskIndexThreshold configuration parameter. Enter a value between 0 and 1.

    The default value is 0.5. That means, the attestation object's risk index must be less than 0.5 for granting approval to be recommended.

  5. Set the approval rate threshold in the QER | Attestation | Recommendation | ApprovalRateThreshold configuration parameter. Enter a value between 0 and 1.

    The default value is 0.5. That means, if more than 50% of all previous attestation cases of this attestation object were approved using the same approval procedure, granting approval is recommended.

  6. Specify the number of days after which user accounts are considered unused in the TargetSystem | UNS | UnusedUserAccountThresholdInDays configuration parameter.

    The default value is 90. That means, if the time of the last login with a user account is less than 90 day ago, granting approval is recommended.

  7. Create an approval workflow in the Manager and insert an approval step with the following data as the first approval level:

    • Approval procedure: EX

    • Event: RecommendationAnalysis

    The event starts the ATT_AttestationCase_Recommendation process, which runs the ATT_AttestationCase_Recommendation script. The script runs automatic approval.

  8. Add an approval level to manual approval.

  9. In case denying approval might be recommended or no recommendation can be made, connect this approval level to the deny connection point at the first approval level.

  10. (Optional) If the request is not to be approved automatically, connect the connection point for granting approval at the first approval level to an approval level for manual approval as well. This means that attestation cases have to be approved manually even if granting approval is recommended.

  11. Create an approval policy and assign it to the approval workflow.

    • Use this approval policy for attesting.

Related topics
相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级