<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
Access Request Expected Reviewer Self-Attestation Behavior
Identity Governance
Okta Classic Engine
Okta Identity Engine
Overview

Access Requests (Request Types and RCAR) can be configured to explicitly or dynamically assign approvers to tasks using options such as a Group or Group Owners. This article explains the expected behavior when auto-assignment results in a potential self-approval scenario within Resource Catalog Access Requests (RCAR) and Request Types.

Applies To
  • Requesters & Approvers
  • Okta Identity Governance (OIG)
  • Access Requests
  • Request Types
  • Resource Centric Access Requests (RCAR - Conditions/Sequences)
Cause

Okta Identity Governance—Access Requests attempts to prevent self-attestation of approvals to enforce a "Separation of Duties" mindset. 

However, the specific behavior can differ depending on the type of reviewer assignment (Group or Group Owner) and the number of individuals within that group or assigned as owners, as well as whether the request is handled via RCAR or legacy Request Types.

Solution
The following is the expected behavior for both Resource-Centric Access Requests (RCAR) and Request Types:
  • Group or Group Owner Assignments: The auto-assignment process does not allow for self-approval when the reviewer is assigned via a Group or Group Owner, regardless of whether the requester is the only user in the group/owner assignment or if there are multiple users. The system is designed to prevent the requester from being auto-assigned the approval task in these scenarios. The resulting approval task will be left unassigned.
  • Requester's Manager: Self-attestation is blocked. If the requester's manager is set to themselves, the approval task will be left unassigned.
  • Delegation: Self-attestation is blocked. If the delegated approver is the same as the requester, the approval task will be left unassigned.
  •  A specific User: This option explicitly defines a single target user for Approval. When using explicitly defined assignment options, self-attestation is allowed if the Requester and the defined user as the Approver are the same.
Assignment options are only available in Request Types:
  • Requester: This target option allows for explicit selection of the Requester to also be the Approver.
  • Request assignee & A member of: These options allow for the selection of Team Members inside of Access Requests. Teams provides an assignment option of "Rotate through all users" or "A specific user". When the requester is also a Team member and "Rotate" is configured, self-attestation will not occur. If the Requester is the only user in the Team, the task will be left unassigned. If "A specific user" is configured and the requester user matches the specific user, they will be selected as the approver.

 

Loading
Access Request Expected Reviewer Self-Attestation Behavior