This article walks through the new Govern Okta admin roles feature in Okta Workforce Identity Cloud (WIC).
- Overview of the Feature
- Enabling the Feature
- Create Admin Role Bundles
- Create and Test Access Requests
- Access Certification of Admin Roles
- Reporting
- Conclusion
Overview of the Feature
This feature builds on the flexible and customizable 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 applied to it. These are:
- Admin role bundle is a combination of role and resource set. Govern Okta admin roles treat an admin role bundle as a group of entitlements that are associated with the Admin Console.
- Access Requests streamlines 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 to 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.
For users familiar with Okta Identity Governance with Entitlement Management, these concepts will be familiar. 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 is enabled and how to set up and use admin role bundles, access requests, and access certification.
Enabling the Feature
This feature is already GA for OIG customers. For non-OIG customers, it is in early access and being progressively assigned to Okta WIC orgs. Once assigned to an org, it will appear in the Settings > Features list and be enabled.
Once available, enable the feature. To confirm that it is enabled, go to the Security > Administrators menu item and check that the Governance tab is there.
Once enabled, Admin role bundles and Access requests for the bundles can be created. Check the Get started page in the product documentation to ensure everything is 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. Specify the admin role to which this bundle will apply.
NOTE: Only one role can be associated with a bundle (although multiple bundles could apply to the same admin role).
Some roles, such as the Super Administrator role above, do not allow for further access restriction. However, most admin roles will allow for applying resources or resource sets. For example, the following role bundle restricts the Application Administrator role to some specific application instances.
When saving the bundle, a confirmation dialog will display. It can be closed manually or automatically.
Once admin role bundles are created, access requests can be applied to them.
Create and Test Access Requests
This section will examine creating and running Access Requests on Admin role bundles.
Create an Access Request
The behavior of creating an Access Request will depend on whether this is the first time it has been created. Access Request instances are called conditions, as they define the conditions for a request.
First Time
- To create a new Access request, click on the Access request button.
- If this is the first time this has been done in the org, some additional backend provisioning will be required, and the message shown below will display.
- Refresh until the Create condition button is available.
- Click the + Create condition button to create a condition.
Access Requests use the same functionality as in the Okta Access Requests component (also shipped with Okta Identity Governance and Okta Privileged Access) but use a new interface embedded in the Okta Admin Console.
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 groups within Okta. This is equivalent to the Audience definition in Access Requests, except it allows for multiple groups that reside within Okta.
In this example, an Okta group 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. A library of approval sequence patterns can be built and used in different Access request conditions. Some requests may need multiple levels of approval (a user's manager and a service owner group), so they can share a sequence to achieve that.
NOTE: Given the risk associated with Admin roles, the implementation requires at least one level of approval. With the Govern Admin roles feature, it was decided to enforce at a minimum of one approval as Okta Admin roles are considered high-risk entitlements but allowing multiple levels easily.
Click the Select sequence button to see the sequences from which to select. The first time, sequences must be created as there are no pre-existing sequences to select.
Create Approval Sequence
- To create a new sequence, click the plus icon beside Create sequence.
A new browser tab opens, and the new interface for creating or modifying sequences is displayed (equivalent to Request Types in Access Requests). A standard template sequence is shown with the Trigger, an Approval steps section, and a Deliver step. The Trigger or Deliver steps cannot be modified, but it is possible to modify the Approval steps to add more than one required approval.
- To give the sequence a name, click the pencil icon.
- Templates are also new; this is where pre-built patterns of approvals are commonly used by other customers.
- Give it a Name and Description, then click Continue.
The user’s manager is set as the first approver for this sequence.
- Select the first Approval step, and select the Requester’s manager for the Assign to.
It is not possible to name the approval steps.
- Enter the second approver (Optional).
This example sets the second approver to a specific user. However, it could be set to an Okta group or Okta group owners. (For example, 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. This would make this sequence reusable across different groups.)
Extra steps can be added by using the plus icons between the existing steps.
In this example, a question is being added to get a business justification from the requester. Clicking the plus icon allows for the selection of different steps that can be added, such as questions and actions. The question option is selected and the Prompt set
- When finished, save the sequence and close the tab.
- To see the new sequence in the list, 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: There are some limitations regarding 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 is not visible in the Request Catalog. To enable a condition, 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 multiple Admin role bundles were 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 (for example, the sequence created above). In this case, there was a user’s manager approval step and then a second approval step.
The functionality of performing approvals is the same as it is within Access Requests. The reviewer (such as the requester’s manager) will get an email indicating they have a request to review. In this case, the manager selects the Request Access tile on their Okta Dashboard.
The manager is presented with an open request needing action.
They open the request, see information about it, and have the option to Approve or Deny it.
Once the manager approves it, it proceeds to the second-level approver(optional). Once they approve it, the request is complete, and access is granted.
Access Granted
When the request is completed, the user receives an email to indicate that it has been completed. If they refresh their Okta Dashboard, they will see that the Admin button has appeared.
When they go into Okta, they see the full list of menu items as they are a Super Admin.
Based on how this was defined in the example, this access will be automatically removed after two hours.
Access Certification of Admin Roles
The other governance control applied to the Admin role bundles is Access Certification. Access review campaigns can be created and executed for the Admin role bundle entitlements in the same way as 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, select the 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: Some conditions, mostly relating to self-review, will now allow a campaign to be built. Okta Admin roles are considered high-risk entitlements, so it does not make sense to allow users to re-certify themselves.
Launch the Campaign
The campaign will automatically launch on the specified date/time or can be manually launched, as it does for every other campaign.
In this example, users were not restricted, so every user assigned to an Admin role (whether it is via a bundle, via a group, or directly) will show up. In the example below, the first entry was assigned the Super Admin bundle, whereas the other users were assigned via traditional approaches.
This campaign is now launched, and notifications have been sent to the reviewers.
Review Access in the Campaign
As a reviewer, review a campaign in the same way any other campaign is reviewed. It may be via the link in the email or by clicking the Okta Access Certification Reviews tile on the Dashboard and selecting the campaign.
When reviewing a user-resource entry, click on the row to see more details about the entry. In this example, the user is assigned to the Super Admin bundle (with the bundle description shown) and what the bundle assigns. The reviewer can use this information to decide whether to approve or revoke the bundle.
This completes the example of building and running an Access Certification campaign for an Admin role bundle.
Reporting
Both OIG and non-OIG customers will be able to run the Campaign Summary and Campaign Details report to view these campaigns.
Conclusion
This article provides a technical walkthrough of the Govern Okta admin roles feature. It looks at the Admin Console application “entitlements”—the Admin role bundles—and walks through the creation and use 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 the org’s admin roles and resources.
- Time-bound admin access helps ensure 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 the review of users’ admin role assignments periodically to avoid the accumulation of elevated or privileged access.
The 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.
Related References
- To view feature requests and upvote product enhancement requests, please visit Okta Ideas.
- Access Certification documentation for Admin Roles
- Preconfigured Admin Campaign
- Govern for admin roles video
- Troubleshooting Admin Role Campaigns
- Looking for Okta Identity Governance help? Visit the Okta Identity Governance Product Hub or schedule Office Hours with the Okta Identity Governance team.
