A Look at the new Govern Okta Admin Roles feature

This article is a walkthrough of the new Govern Okta Admin Roles feature in Okta Workforce Identity Cloud (WIC).

Overview of the Feature

This new feature builds on the flexible and customisable administration roles that have been available on Okta WIC for some time. It treats the Okta Admin Console as an application with entitlements and governance controls are applied to it. These are (from the help documentation):

• Admin role bundle is a combination of role and resource set. Govern Okta admin roles treats an admin role bundle as a group of entitlements that are associated with the Admin Console.
• Access Requests allows you to streamline the process of requesting access to an admin role bundle. It provides an easy and secure way for users to submit requests, and automatically sends those requests to approvers for action. Once a request is approved, the user has time-bound access to the requested admin role.
• Access Certifications helps you create audit campaigns to periodically review, approve, and revoke users’ admin role assignments. This helps avoid the accumulation of elevated or privileged access to a resource.

If you are familiar with Okta Identity Governance with Entitlement Management these concepts will be familiar to you. Some of the user interface screens will be familiar, but this function is the first to use the new request catalog interfaces.

The rest of this article is a technical exploration of the new feature, looking at how it’s enabled, and how you setup and use admin role bundles, access requests and access certification.

Product documentation can be found at: https://help.okta.com/oie/en-us/content/topics/security/governance-admin-roles/govern-admin-roles.htm.

There is also a video of this functionality: https://www.youtube.com/watch?v=JyeJhv5E09E.

Enabling the Feature

This feature is in early access and is being assigned progressively to Okta WIC orgs. Once it is assigned to an org, you will see it appear in the Settings > Features list to be enabled.

You will need to enable it.

To confirm the feature is enabled, go to the Security > Administrators menu item and check that the Governance tab is there.

You can now create Admin role bundles and Access requests for the bundles.

It’s worth checking the Get started page in the product documentation to ensure you have everything set up correctly.

Create Admin Role Bundles

Selecting the Governance tab presents a new page that describes the new Govern Okta admin roles function and allows the creation of Admin role bundles and Access requests.

To create a new bundle, click the + Create bundle button.

On the next page specify a Name and Description. You also need to specify the Admin role that this bundle will apply to. Note that you can only associate one role with a bundle (although you could have multiple bundles applying to the same admin role).

Some roles, such as the Super Administrator role above, does not allow further restricting access. However most admin roles will allow applying resources or resource sets. For example the following role bundle restricting the Application Administrator role to some specific application instances.

When saving the bundle you will get a confirmation dialog (which you can close or it will go away itself).

With admin role bundles created you can create access requests to apply to them.

Create and Test Access Requests

In this section we will look at creating and running access requests on Admin role bundles.

Create an Access Request

The behaviour on creating an Access request will depend on whether this is the first time you are doing it, or not. Access request instances are called conditions, as they define the conditions for a request.

First Time

To create a new Access request, you click on the Access request button. If this is the first time you’ve done this in the org, there will be some additional backend provisioning required and you will see the message as shown below.

Refresh until the Create condition button is available.

Create Condition

Click the + Create condition button to create a condition.

Access requests are using the same functionality as in the Okta Access Requests component (also shipped with Okta Identity Governance and Okta Privileged Access) but is using a new interface embedded in the Okta admin console. If you are familiar with Access Requests in OIG or OktaPA, the following will make sense.

The Access request condition has four sections: Requester scope, Access scope, Access duration and Approval sequence.

The Requester scope defines who can request this access – either everyone or a set of Okta groups. This is equivalent to the Audience definition in Access Requests (but you can specify multiple groups and there are no Teams).

In this example there is an Okta group that contains the admins who are allowed to request access to the Super Admin role.

The Access scope section defines which Admin role bundles apply to this condition. This is equivalent to the assignment actions in Access Requests.

The Access duration section defines how long a user will retain the Admin role bundles. It could be something the user specifies (question) or fixed. In the example it is set to 2 hours – two hours after the user gets access to the Super Admin role, they will automatically lose it. This is equivalent to using a timer in Access Requests between assigning access and removing access.

The last section of a condition is the Approval sequence. You can build up a library of approval sequences that can be used in different Access request conditions. You may have some requests needing two levels of approval (say users manager and a service owner group), so they can share a sequence that does that. Note that the implementation for Admin roles requires a minimum of two levels of approval given the risk the roles represent.

Note that with the Govern Admin roles feature, it was decided to enforce a minimum of two levels of approval as Okta Admin roles are considered high risk entitlements.

Click the Select sequence button to see the sequences you can select from.

The first time you run this, you will need to create a sequence (there are no pre-existing sequences to select from).

Create Approval Sequence

To create a new sequence, click the plus icon beside Create sequence.

A new browser tab opens and you are presented with the new interface to creating or modifying sequences (equivalent to Request Types in Access Requests). A standard template sequence is shown with the Trigger, two Approval steps and a Deliver step. You cannot modify the Trigger or Deliver steps, but you can modify the Approval steps

The first thing to do is to give the sequence a name. Click the pencil icon.

Give it a Name and Description then click Continue.

For this sequence we’re setting the user’s manager as the first approver. Select the first Approval step and select Requester’s manager for the Assign to.

Note that you can’t name the approval steps.

For the second approver we set it to a specific user but it could be an Okta group or Okta group owners (e.g. it might make sense to have a group of people who can request admin access, and have the owners of that group be the access approvers, which would make this sequence reusable across different groups).

We can also add extra steps in by using the plus icons between the existing steps.

In this case, we’re going to add a question to get a business justification from the requester. Clicking the plus icon allows selection of different steps that can be added, such as questions and actions. We select the question option and set the Prompt.

When finished you Save the sequence and close the tab. To see the new sequence in the list, you click the refresh icon.

The new sequence should appear.

Assign an Approval Sequence

To assign the sequence, click the sequence and the Select sequence button.

The sequence is now assigned to the Access request condition.

The last thing to do is to Create the condition.

Note that currently there are limitations around editing Access request conditions and sequences that will be improved over time.

Publish an Access Request Condition

A new Access Request condition is created in a Disabled state. This means it’s not visible in the Request Catalog.

To enable a condition you need to use the Enable action.

Then it should show as enabled.

This new Access request condition is now ready for use.

Request Admin Role Access

This section walks through the request flow.

User Request

The user requesting access to an Admin role bundle, uses the new Request access button on the Okta Dashboard.

This opens the new Request Catalog view. All applications that the user can request are shown in their own tile. In this case only the Okta Admin Console application is shown.

Selecting this application tile presents the access level selection option. If there were multiple Admin role bundles exposed for this user, they would see multiple items in the list.

There is also information on the duration of access and the Business Justification field from the question added to the sequence above.

The user selects the access level, enters a Business Justification and clicks the Submit request.

Manager Approval

Once submitted it follows the approval sequence for this access level (i.e. the sequence created above). In this case there was the user’s manager approval step, then a second approval step.

Performing approvals is the same as for older Access Requests. The reviewer (such as the requester’s manager) will get an email to say they have a request to review. In this case the manager selects the Request Access tile on their Okta Dashboard.

They are presented with open request needing action.

They open the reuqest and can see information about the request. They have the option to Approve or Deny the request.

Once approved it proceeds to the second level approver. Once they approve, the request completes and the access is granted.

Access Granted

When the request completes the user gets an email to indicate it has completed. If they refresh their Okta Dashboard, they will see that the Admin button has appeared.

When they do into Okta they see the full list of menu items as they are a Super Admin.

After two hours this access will be automatically removed.

Access Certification of Admin Roles

The other governance control applied to the Admin role bundles is Access Certification. You can create and execute access review campaigns for the Admin role bundle entitlements in the same way that you do for any other application entitlements.

Create a Campaign

Creating a campaign is the same as creating any other Resource campaign in Okta. On the Resources page, you need to select type of Applications, enable the Review entitlements option and select the Okta Admin Console application.

The subsequent steps to create a campaign are the same as for other campaigns.

Note that there are some conditions, mostly relating to self-review, that won’t allow a campaign to be built. Okta Admin roles are considered high risk entitlements, so it doesn’t make sense to allow a user to recertify themselves.

Launch the Campaign

The campaign will automatically launch on the specified date/time or can be manually launched. This is the same as for every other campaign.

In this example, we did not restrict the users, so every user assigned to an Admin role (whether it’s via a bundle, via group or or directly) will show up. In the example below, the first entry was assigned the Super Admin bundle, whereas the other users were assigned by traditional approaches.

This campaign is now launched and notifications have been sent to the reviewers.

Review Access in the Campaign

As a reviewer, you review a campaign in the same way that you review any other campaign. It may be via the link in the email sent or by clicking the Okta Access Certification Reviews tile on the Dashboard and selecting the campaign.

When reviewing a user-resource entry, they can click on the row to see more details about the entry. In this case they can see that the user is assigned to the Super Admin bundle (with the bundle description shown) and what the bundle assigns. This can be used by the reviewer to decide if they should approve or revoke the bundle.

This completes the example to building and running an Access Certification campaign for an Admin role bundle.

Conclusion

This article has provided a technical walkthrough of the new Govern Okta admin roles feature. It has looked at the Admin Console application “entitlements” – the Admin role bundles. It has walked through the creation and user of both Access Requests and Access Governance capabilities for them.

To borrow from the product documentation, The Govern Okta admin roles feature provides these important security features:

• Orgs have more control over who can access your org’s admin roles and resources.
• Time-bound admin access helps ensures that sensitive permissions and resources are protected.
• Unnecessary standing admin assignments are eliminated.
• Users can easily request admin access, and orgs can quickly grant and revoke that access.
• Campaigns allow you to review users’ admin role assignments periodically to avoid accumulation of elevated or privileged access.

Your Okta implementation will benefit from improved security and reduced risk of compromise if the Govern Okta admin roles feature is deployed effectively allowing the use of standing privileges to be significantly reduced.