OIG Access Requests – Understanding User Grouping

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 that OIG Access Requests is the old atSpoke product. The term “Okta” in this article refers to the Okta Identity Cloud. The term “Access Requests” in this article refers to the tenant/instance providing the access requests and workflows functionality (this was atSpoke). Also a recent change in Access Requests was to replace the term “workflows” with “request types”. This article uses the term workflows.

This article is looking at the groupings applied to objects within Access Requests, not the the admin access into Access Requests from Okta.

Summary (TL/DR)

There are four grouping mechanisms in OIG Access Requests:

• Teams – these are within Access Requests and represent groups of users. They are defined in Access Requests and do not currently 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 Access Requests. 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 – Access Requests 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 Access Requests 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.

Function	All (AR) Users*	(AR) Team	Okta Group	Resource Lists / Sublists	Configuration Items**
Workflow owner (“Team”)		YES
Workflow audience (who can run)	YES	YES	YES
Task assigned-to (participant)		YES	YES
Selection list in Questions				YES	YES
Actions – Assign Okta user to specific list item (group/app)				YES

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

** – 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) teams for flow ownership and have everything else in a workflow 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 Access Requests. They have no external connection (e.g. no link to Okta objects). They can have different icons and colours to differentiate them.

Teams are created/managed in the Access Requests UI, under the Teams menu item. Members are local users defined in Access Requests, 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 Access Requests app in Okta.

When the synchronisation runs, the push groups will appear in the Access Requests Okta Groups list in the configuration setting.

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

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 workflow in Access Requests, you need to define two scopes, the Team it is assigned to and the Audience.

The Team is the team of users that the workflow instance will be assigned to, i.e. who owns the flow. This comes from atSpoke’s more general ticketing mission. There can only be one team assigned and it must be an Access Request 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 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.

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 Workflow

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.

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

Selection Lists in Steps in a Workflow

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.

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

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.

This concludes the different functions where user groups are used.

Conclusion

This article has looked at the different user groupings (Access Requests Teams, Okta Groups and lists from Okta) and the different Access Requests workflows functions. The following table shows these groupings and which functions they apply to.

Function	All (AR) Users*	(AR) Team	Okta Group	Resource Lists / Sublists	Configuration Items
Workflow owner (“Team”)		YES
Workflow audience (who can run)	YES	YES	YES
Task assigned-to (participant)		YES	YES
Selection list in Questions				YES	YES
Actions – Assign Okta user to specific list item (group/app)				YES

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

It should be possible to only use the (Access Request) 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.