Requesting Roles Through OIG Access Requests

This article looks at how Okta Identity Governance (OIG) can be used to provide a role-request feature in Access Requests. The example used is roles for Salesforce.

Article contents:

What Roles?

If you’re familiar with the Okta Identity Cloud data model, you will know there are users, groups and applications but no roles (other than roles to administer Okta itself). But groups can be used to “group” users for different functions, such as applying authentication policy and application entitlements. Many customer deployments treat groups as roles for the latter – groups assigning users to applications may be tied to a job function.

In addition to this coarse-grained assignment, many applications in Okta support fine-grained entitlements. For example when looking at Salesforce.com, users or groups can be assigned to specific SFDC roles and licenses. It makes sense (even “best practice”) to assign groups to these applications and set these fine-grained entitlements at the group level, and then manage user membership to the groups rather than assigning individuals to applications. This strengthens the model of groups as roles – providing both coarse- and fine-grained entitlements. See https://iamse.blog/2022/03/22/fine-grained-entitlement-reporting-with-workflows/ for more discussion on managing fine-grained entitlements in Okta.

The following figure shows the relationships discussed above.

An Example – Salesforce.com and Some Role Groups

Let’s look at an example of this. I’ve created four groups in Okta to represent roles against Salesforce.com.

These are assigned to the Salesforce.com application.

If you drill into the group-level assignments you see that a specific Salesforce.com role has been assigned to the Okta group.

Thus the Okta groups represent roles, and also assign a fine-grained permission (in this case a role) in Salesforce.com.

How do we expose these to be requested in Okta Identity Governance (OIG) Access Requests? Let’s have a look at two ways – a group request and a label-based request. Note that the approaches shown below are based on the current Limited Early Access code and features may be added to OIG Access Requests in the future that may mean different approaches can be used.

Requesting The Role Groups Directly

A key driver for Access Requests is to keep it as simple as possible for end users. If you have a simple and well-understood naming standard applied to your groups, you could just expose them in an Access Request flow as they are.

We will use the groups and group assigments above.

Using Configuration Items for a List of Groups

The first thing needed is a Configuration item with the groups you want to expose.

This list contains the four groups.

Access Request Flow For The Group List

Next we can build a workflow to assign the user to the role. It will prompt for the group and a justification, get manager approval and then assign the user to the group.

The following figure shows the entire workflow – we will drill into the detail of each step below.

The first step, Role, is a simple Dropdown question using the Configuration Item from above.

It’s important that the Role is a required field as the flow will fail if nothing is selected. The Dropdown is assigned to the Configuration item SFDC-Role-Groups from above. The logic assumes a single role is selected (there is no logic in the example flow to support multiple selections).

The Justification and Manager Approval steps are straightforward.

The last steps (Assign User to XYZ) are basically a case statement, with a single step for each role group that could be chosen in the Role question. Let’s look at one of them (they are all the same)

This step uses the standard [Okta] Add user to group action. When enabling the Run automatically checkbox, the required fields (email and group) are exposed. The email address is that of the requester (the user to be assigned to the group). To get the group, we need to select 1. A configuration list item, then 2. the Groups object (the full list of Okta groups), and finally 3. the actual group to be assigned.

The image above shows the logic applied to the step. It will only run if the Manager has approved the request and the role selected by the user matches the group name for this step.

As the second condition is based on the role value from the question, and that is tied to the Configuration item with the list of groups, so you can only select a value from that Configuration list for this condition.

Running the Access Request Workflow

Let’s see this in action. The user initiates the Access Request workflow.

There request flows and is approved.

The user is added to the group in Okta.

This proves the workflow works as intended.

Requesting The Role Groups via a Label

The previous example shows the user being presented a list of role groups, where the group names follow a standard making them easily understood. But what if the Okta group names assigned to the application don’t make sense to the end user? You can use the same approach, but instead of presenting a list of group names, you can present a list of labels.

I will summarise below, rather than going into the detail as above.

Configuration Item for Role Labels

For this example, I have duplicated the above Configuration item and changed the group names to labels.

This will be used in the Access Request workflow.

Access Request Workflow for the Role Label List

The flow is basically the same as the previous one, except using in the new SFDC-Role-Labels Configuration Item list, and different Logic for the conditional steps.

The Role dropdown question is using the new Configuration item – SFDC-Role-Labels, and the conditional logic in the Assign to XYZ steps check for each of the SFDC-Role-Labels values.

Running the Access Request Workflow

The end user experience is fundamentally the same but they see a list of role labels.

The rest of the workflow proceeds as above.

Conclusion

This article has discussed how Okta groups can represent roles, and be used for both coarse-grained (application-level) and fine-grained (application attribute-level) entitlement assignment. It has shown two examples of using OIG Access Request Configuration item lists and workflows with conditional logic to present lists of roles (by group name or role label) and have the right role be assigned to the user.