By David Edwards, Okta Senior Product Acceleration Specialist

OVERVIEW

Understanding user grouping mechanisms in the Okta Identity Governance (OIG) Access Requests mechanism is important to building and running access request flows. It can be confusing and this article aims to address the confusion.

Note - this article was originally written in May 2023 before the release of the newer Access Requests functionality. This update addresses terminology changes in response to the newer functionality.

The term “Okta” in this article refers to the Okta Workforce Identity platform. The term “Access Requests Platform” in this article refers to the tenant/instance providing the access requests and workflows functionality (this was atSpoke). The Access Request Platform supports two type of access request flows: the "Request Type" which is the legacy flow type where flows are developed and managed within the Access Requests Platform, and the newer "Request Conditions" where the flows are developed and managed within the Okta Admin Console (but executed in the platform). There are functional differences between the two types that will not be covered here.

The remainder of this article is focused on the Request Types that are built and developed in the Access Request Platform. It is is looking at the groupings applied to objects within Request Types, not the admin access into platform from Okta. There are four grouping mechanisms in OIG Request Types:

• Teams – these are within the Access Requests Platform and represent groups of users. They are defined in the platform and do not link to Okta groups. They can be used to define who can run a flow (requesters) and who can participate in steps in the flows (participants).

• Okta Groups – these are groups that have been pushed from Okta into the platform. The mapping of users to these groups is done in Okta. They can be used to define who can run a flow (requesters).

• Okta Resource Lists – the platform has lists that can be used for picking items in flows (e.g. list of apps or groups a user needs to be added to). There are two lists automatically pulled from Okta – a list of all Okta groups (“Groups”) and a list of all applications (“Applications”). The list items are the group (or application) names. These are controlled by the integration between Okta and the Access Requests Platform and cannot be changed by the administrators.

• SubLists – The sublists of groups (or apps) are built from the existing Groups (or Applications) configuration items (“Okta resource lists”). An administrator controls the membership of the list. You have no visibility into the members of the groups, just the group names.

The following table shows these groupings and which functions they apply to. Note ARP = Access Requests Platform.
 

* – There is an “Everyone” category for the Audience (“Everyone in <instance>”). This is all users in the Access Requests Platform.

** – Configuration items are also lists, but not group/app lists. They are static lists of items (strings) used for selection in flows and cannot be tied back to Okta objects. You cannot create a configuration item list of group names, for example, and have the flow use them to update groups in Okta.

It should be possible to only use the (Access Request Platform) teams for flow ownership and have everything else in a Request Type based on objects in Okta. This would significantly simplify administration of users and groups.

The groupings and functions are covered in detail in the remainder of the article.

Defining/Configuring the Different User Grouping

This section of the article looks at the different user group mechanisms and how they are defined and/or configured. The next section will look at how they are used.

Teams

Teams are local groups defined within the Access Requests Platform. They have no external connection (e.g. no link to Okta objects). They can have different icons and colours to differentiate them.

Teams in the Access Requests Platform

Teams are created/managed in the Access Requests Platform UI, under the Teams menu item. Members are local users defined in the Access Requests Platform, but as there’s no way to locally create users, the user pool is the list of users sync’d from Okta (i.e. those in the group(s) or user(s) assigned to the Access Requests app in Okta).

Any teams used for flows that will perform actions in Okta must be assigned to the Okta connection (in the Settings > Integrations page). This will be discussed in more detail below.

Okta Groups

Okta groups (with membership) can be pushed from Okta to Access Requests. They are defined as Push Groups in the Okta Access Requests app in Okta.

Okta Groups Pushed to the Okta Access Requests app (representing the Access Requests Platform)

When the synchronization runs, the push groups will appear in the Platform's Okta Groups list in the configuration setting.

Push Group in the Access Requests Platform

These groups do not need to be assigned to the Okta connection in the Okta Access Requests app.

Okta Resource Lists

Okta Resource lists consists of the Groups list, the Applications list and any sublists defined. They are defined in the Settings > Configuration section of the Access Requests admin UI.

The Groups list contains an item for each group (group name) in Okta.

A sublist can be created here, selecting items from either the Applications or Groups lists.

Once you assign groups (or apps) to a sublist from a source list (Groups or Applications) the source list cannot be changed (i.e. before removing groups/apps in Okta you need to check to see if they are being used in sublists).

Other Lists (Configuration Items)

You can also create local lists of strings (like the Buildings in the following screenshot) to use as pulldown selection lists in flows. They aren’t user groupings in the context of this article, but are treated like other lists mentioned earlier.

Now that we’ve looked at the different user groupings, let’s look at how they are used.

Use of the Different User Groupings

The user groupings can be used in the scope of a workflow (who owns and who runs it), selection lists and task participants.

Scope of a Workflow

When defining a flow in the Access Requests Platform, you need to define two scopes, the Team it is assigned to and the Audience.

Defining the Team and Audience for a Flow

The Team is the team of users that the workflow instance will be assigned to, i.e. who owns the flow. There can only be one team assigned and it must be an Access Request Platform team – it cannot be an Okta group.

The Audience is who the workflow is available to, i.e. who can see and run the flow. There are three options:

1. Everyone in your Access Requests Platform instance (i.e. everyone assigned to the app in Okta and sync’d to Access Requests)

2. Members of the “Team” that owns the flow

3. One of the Okta Groups you have pushed from Okta (see above).

This is shown below.

Audience Selection for a Flow

Note that there is a toggle under Audience to make the workflow visible to everyone, rather than limited to the selected group.

Participants (Assigned To) in Steps in a Flow

All of the steps (Questions, Tasks and Actions) will need to be assigned to someone. Questions are normally assigned to the requester. Actions are normally assigned to the service performing the action, such as Okta for Okta actions.

Tasks may need to be assigned to someone else, like a request assignee, requester’s manager of a specific user. From a group perspective a task might be assigned to any member of a Team or an Okta Group.

Assigning Users to a Task

Thus you have the option of managing participant lists (groups) in Access Requests (Teams) or Okta (Okta Groups).

Selection Lists in Steps in a Flow

Some workflows will prompt users from a selection list. For example, selecting an application or group to get access to, or selecting a site they need access to. These lists are based on the Okta resource lists or Configuration items (lists) defined in the Settings.

Using Configuration Items (Lists) in a Step

In the example above, the user will be prompted to select a “Site” from a dropdown list. This list is populated from the Configuration item “Buildings”. But any Configuration item could be presented as a list, including the list of all Okta apps, groups or sublists you have defined in Access Requests (see above).

Selecting item

Some of the Actions available also present Configuration items for configuring the action (i.e. used in workflow configuration by an admin, not something presented to an end user at workflow execution). For example, you may need to specify an application or group to provision to a user, as shown below.

Using Configuration Items

This concludes the different functions where user groups are used.

Conclusion

This article has looked at the different user groupings (Access Requests Platform Teams, Okta Groups and lists from Okta) and the different Request Type functions. The following table shows these groupings and which functions they apply to. Note that ARP = Access Requests Platform.

• – There is an “Everyone” category for the Audience (“Everyone in <instance>”). This is all users in the specific Access Requests Platform.

It should be possible to only use the (Access Request Platform) teams for flow ownership and have everything else tied to a workflow based on objects in Okta. Thus users and applications could be managed in groups in Okta and workflows would not need to be changed to accomodate user/app changes. This would significantly simplify administration of users and groups.

The above is for the older "Request Types" that are defined and managed in the Access Requests Platform. The newer "Request Conditions" only support the use of Okta Groups and Okta Group Owners (which may be groups or individuals) in approval and tasks steps. It does not use the other constructs listed in the above table.