What is Requester Scope in Resource Centric Access Requests aka RCAR?  Well it's a very simple way to define which resources are requested by whom.  We’re going to dive into why it’s important and how you can take advantage of this logic natively supported with some company scenarios.

OVERVIEW

Access Requests built with RCAR are composed of 4 components.  

• Requester scope - Who can make the request.

• Access level - Which resources are request-able.

• Access duration - Permanent, fixed duration, request-able duration up to max value

• Approval Sequence - a sharable Approval Sequence made up of question(s), approval(s), task(s) and executing a Delegated workflow.

Note:  Requester Scope can be composed of one or more groups that exist within Okta (Any kind of group that is!).  In comparison to V1 Request Types that only use one Okta Push Group. 

How to use the Requester scope - Scenario 1

“The Akto company is implementing a least privilege access model while carefully monitoring license usage for its highly sensitive accounting applications.  To achieve this, the CISO wants to design the access request flows that accommodate two distinct  user groups. 

• Employees in the Accounting department, who can request permanent access

• Employees outside the Accounting department, who are still permitted to request access - but must go through additional approval steps and are only granted short-term access.

The goal is to create a request configuration that supports both user groups while enforcing stricter scrutiny and time-bound access for users outside the Accounting department.  Users that show their department as Accounting will automatically be added to the Accounting group.”

IT Builds two Conditions on the Accounting application using the following configurations.

Condition 1:

Accounting Condition (save and enable when complete)

 Condition 2: 

Everyone Condition (save and enable when complete)

Note: Depending on the order in which each condition will depend on the priority set.  If the “Everyone condition” is created first it will show on top (higher priority).  Simply drag the Condition below the “Accounting Condition” if needed.

Expected Results

End user Catalog 

Accounting Group Audience -  no duration set

Everyone Audience -  duration set to 8 hours.

How to use the Requester scope - Scenario 2

“The Akto company is enforcing a least privilege model while keeping a close eye on license consumption for sensitive applications used for accounting.   To support this, the CISO wants the administrator to create an access request flow that adapts based on the sensitivity of the group or resource being requested.
Some groups will require higher levels of approval or stricter controls, while others may have a more streamlined path.  In certain cases, users may only be granted short-term access depending on the criticality of the group being requested.
The goal is to build a flexible access request configuration that enforces varying levels of security based on the access target - ensuring appropriate governance without blocking productivity.”

IT Builds two Conditions on the Accounting application using the following configurations.

Condition 1:

Accounting Condition (save and enable when complete)

 Condition 2: 

Everyone Condition (save and enable when complete)

Note: The order of these Conditions is not relative since both are using the same audience in the Requester Scope.

Expected Results

End user Catalog 

Group 1 no duration set

Group 2 or 3 duration set to 1 week

Summary

Akto is enforcing a least privilege model to secure access to its most sensitive, license-controlled applications. Two key access request scenarios are being addressed:

1. Access Based on Target Resource Sensitivity
   The access request process dynamically adjusts depending on which group or resource is being requested. Highly sensitive groups require stricter approvals and shorter access durations, while less critical groups follow a streamlined path. This ensures tighter governance over sensitive areas without hindering user productivity.

2. Access Based on Requester Group
   The company also differentiates the request process based on the user’s attributes like department or title. For example, users in the Accounting department receive standard access, while others outside the department must complete additional approvals and are granted only temporary access. This maintains control while still enabling broader collaboration when needed.

Together, these configurations create a flexible and risk-aware access management framework that aligns access decisions with both “who is requesting” and “what they are requesting”.

RELATED REFERENCES

• Controlling Audience with RCAR

• Guide on using Okta Identity Governance API’s

• Corporate blog: Okta Identity Governance: A Unified IAM and Governance Solution

• Improve Your Security Posture with Okta Identity Governance (OIG)