Okta has released into Early Access a new feature called the Access Request Conditions and Resource Catalog, or more simply the Resource Catalog. This is a new way to configure and use access requests in Okta Identity Governance. This article shows how this can be applied to access within Okta Privileged Access.
Introduction
Okta Privileged Access has users and groups provisioned from Okta. The groups are used to assign users to Okta Privileged Access administration roles and security policies. So whilst the access is defined in Okta Privileged Access, users are assigned to groups in Okta and then pushed to Okta Privileged Access.
As we’re concerned about controlling privileged access, it makes sense to apply stringent controls through Okta Identity Governance (OIG) such as access requests processes (with approvals and fixed durations) and access certification to the groups pushed to Okta Privileged Access. A new Resource Catalog feature has been added to OIG to allow requesting access from within the Okta Dashboard.
This article explores using the new OIG Resource Catalog with groups pushed to Okta Privileged Access and assigned to roles and policies. The following figure shows the components involved in what the article will explore.
The bottom of the diagram is Okta Privileged Access with admin roles and security policies, with users assigned via groups. These groups are pushed from Okta (Workforce Identity Cloud).
Within Okta, these groups are exposed for access requests through conditions on the Okta Privileged Access app.
When a user uses the new Request Access function in the Okta Dashboard, they are presented with the apps (in this case Okta Privileged Access) and accesses (in this case groups) they can request. When they request one of these groups, the Okta Access Requests component will drive an approval flow and reviewers (such as the user’s manager) will use the Okta Access Requests component to review and approve/deny the access request.
When access is granted, the user uses the Okta Privileged Access tile on the dashboard to SSO to the Okta Privileged Access and has the roles/policies based on the groups assigned. This will be come clearer as we walk through the sections below.
For more information on Okta Privileged Access, see:
A Quick Revision on Groups in Okta and Access in Okta Privileged Access
Okta Privileged Access is an application in Okta like most other SaaS applications. It supports OIDC and SCIM. It has users assigned to it, either directly or via groups.
Any users assigned to the app in Okta will be provisioned to Okta Privileged Access.
It can also have push groups assigned and these groups (with their membership) will be provisioned to Okta Privileged Access.
These push groups could be mapped to administrative roles in Okta Privileged Access or mapped to security policies to grant access to privileged resources.
Thus Okta Privileged Access policy and admin role membership can be managed in Okta through group management. This could be done through manual administration, APIs, lifecycle (group) rules or using the access requests capabilities in Okta Identity Governance (OIG).
The latter approach is suited to privileged access as you can implement a zero standing privileges model where a user may be defined in the PAM solution but must request appropriate privileged access through a process and have that access automatically removed after a period of time. The remainder of this article will look at how the new OIG Resource Catalog can be used to implement this for Okta Privileged Access.
Building Request Conditions for Okta Privileged Access
In this section we will show how we can configure Access request for Okta Privileged Access using the new Request Catalog feature.
As shown above, Okta Privileged Access is an application in Okta with users and groups assigned. When you enable the new feature, the application will show a new tab called Access requests.
Within Access requests we can define one or more conditions for users to request access. Different conditions can be tied to different user groups, so you might have a low level of access available to all users but administrative access only available to a small group. Conditions also define what access is granted (e.g. application level, groups associated with the app or application entitlements), the duration of access and the approval sequence to run.
For our Okta Privileged Access app, we will set up two conditions:
- A “system admin” condition to request access to a server (one of the server access groups), with manager approval and a two-hour time limit
- A “PAM admin” condition to request access to perform resource or security administration, with both manager and service owner approval, and a four hour time limit
You could assign these conditions to different groups of users (e.g. a system admin group and a PAM administration group) but for this example, we will use a single group (the PAM All Users group assigned to Okta Privileged Access).
Lets walk through the creation of a condition.
Creating the First Condition
On clicking the Create condition button shown above, the administrator is presented with a page to define the condition. It contains the condition name and four sections:
- Requester scope – who can request this access. In this case it is the users in the group PAM All Users
- Access level – whether the user is requesting access to the app or to specific groups associated with the app. In this case it will be the sysadmin groups defined in Okta and mapped as push groups to the Okta Privileged Access app (PAM Linux Sysadmins and PAM Windows Sysadmins).
- Access duration – how long the user retains access. In this case it will be two hours.
- Approval sequence – the approval flow to run. In this case the sequence will prompt for a business justification and request manager approval
The first three for this condition are shown below.
Approval sequences are separate items that can be reusable blocks attached to multiple conditions (for example the sequence we will build for manager approval may be appropriate for multiple conditions, not just this one).
When we click the Select sequence button, there are no pre-existing sequences, so the admin must create a new sequence. This opens a new browser tab where the sequence is defined. It has a name and approval and a set of steps.
In this case we add the steps to:
- Request the Business Justification from the requester (the user requesting access) and
- Prompt for approval from the requester’s (user’s) manager
This is shown below.
This sequence is saved and assigned to the condition.
This condition is then saved (created) and enabled. This application now has one access request condition.
Next we can create the second condition.
Creating the Second Condition
The second condition is similar but with a different set of groups, duration and sequence. This is shown below.
This condition requires a more stringent approval sequence – manager approval and a service owner approval. This is shown below with the first two steps the same as earlier, and a service owner approval set to a specific user (it could be set to the group owners or another Okta group, which would be a more flexible approach).
Again this sequence is saved and assigned to the condition. The condition is then saved and enabled. We now have two access request conditions assigned to the Okta Privileged Access app.
Now that there are two conditions applied to the Okta Privileged Access app, we can test access requests.
Testing the Conditions
Our first user, Larry Linuxadmin, needs to cross to the dark side and perform some Windows system administration. His colleague, Wendy Winadmin has been temporarily assigned to the PAM admin team and needs some admin access.
Larry Requests Access to Windows Sysadmin Permissions
To get the additional sysadmin access, Larry logs into his Okta dashboard and clicks on the Request access button.
This opens the new Dashboard Request Access app where he can see the apps he can request access for. He clicks on the Okta Privileged Access tile.
He is presented with a list of all the accesses he can request.
This list matches all the groups assigned to the two conditions above – the first three shown are on the PAM admin condition, and the last two are on the system admin condition. He see’s the full ist because both conditions are set to a group that he’s a member of.
Note that the description for the access (group) is pulled from the group description. In this case, the group descriptions have been populated with the permissions in Okta Privileged Access (covered in https://iamse.blog/2024/01/02/okta-privileged-access-and-access-certification-getting-roles-into-the-group-description/) and risks (covered in https://iamse.blog/2024/01/02/okta-privileged-access-determining-and-highlighting-risk-in-roles-and-policies/). This is not standard configuration and requires Okta Workflows.
He selects the PAM Windows Sysadmins access and then is prompted for a Business Justification. He enters the justification and submits the request.
This triggers the approval sequence to run. The only approver is his manager, who gets an email telling them there’s a request to review (or if the Slack or Microsoft Teams integration is enabled, they will see a notification there).
The manager goes into the Okta Access Requests app and sees the request awaiting his action.
Selecting the request, he sees the details (who, what app, the group and justification).
He approves the request and the access is granted. This also triggers the timer to automatically remove access in two hours.
Looking at the requested group in Okta, you can see Larry has been added.
The Okta system log shows Larry being added to the group and the group being pushed down to Okta Privileged Access (almost immediately!). Note that it also shows events related to Larry’s request for access which can be used for auditing.
Within Okta Privileged Access Larry has been added to the PAM Windows Sysadmins group and can perform actions assigned to that group (i.e. RDP’ing to a set of Windows servers).
In two hours that access will automatically be revoked and this will also be reflected in the Okta system log.
Wendy Requests Access to PAM Resource Admin Role
Next Wendy Winadmin, who’s been assigned to the PAM admin team for a while, needs to be made a member of the OPA Resource Administrators group so she can manage a project in a resource group.
As with Larry above, she goes to the Okta Dashboard, selects the Request access button and is shown the list of apps she can request access for. She selects the Okta Privileged Access app and is presented with the same list of accesses as Larry saw.
She selects the access, specifies a Business Justification and submits the request. Her manager gets notified, reviews the request and approves.
Wendy hasn’t seen any notification that her request has been completed, so returns to the Request access menu and clicks on the Okta Privileged Access app again. She can see it’s still submitted with a link.
She clicks on the link to view the progress of the request and can see her manager has approved, but it’s still waiting on the service owner.
Once the service owner approves, the access is granted.
We can see she was added to the group in Okta, it was pushed to Okta Privileged Access and she is now a member of the group there.
Wendy SSOs into Okta Privileged Access from the Okta Dashboard and sees she can now access the Resource Administration functions.
After four hours this access will be removed.
Conclusion
In this article we have shown how the new OIG Resource Catalog feature can be used to allow users to request privileged access in Okta Privileged Access from the Okta Dashboard. These access requests are based on being assigned to groups that are pushed to Okta Privileged Access and mapped to admin roles and/or policies to grant access.
The article has shown how these access request processes (conditions) can be built for the Okta Privileged Access app, and then leveraged by end users, with approval flows and fixed access durations.
Centralised management in Okta Identity Governance of groups used in Okta Privileged Access can be effective in applying a Zero Standing Privileges model and reducing the risks associated with using a PAM solution.
2 thoughts on “Managing Access in Okta Privileged Access with the new OIG Resource Catalog”