Okta Privileged Access (OPA) leverages with wider Okta Workforce Identity Cloud capabilities for many use cases. One of these integrations is with the Okta Access Requests components, that comes as part of the Okta Identity Governance (OIG) product, but also ships in a limited form with OPA.
This article explores the two common use cases:
- Access Requests as a PAM Policy Condition
- Access Requests to manage Groups used in OPA
Use of one or both of these use cases allows for a flexible risk-based approach to privileged access.
For more information on Okta Access Requests, see OIG Access Requests page and the Access Requests articles on this site.
Access Request as a PAM Policy Condition
The first use case supports leveraging access requests as a condition in a PAM policy. The scenario is that a group of users has access to privileged resources, but at the time of access there needs to be just-in-time (JIT) approval by a manger, service owner or some other person/team.
Overview
OPA provides all of the components to support this use case. It involves the OPA client working with the OPA cloud service and triggering an access request flow in Access Requests. The flow is shown in the following figure.
The steps are:
- The user requests access to a resource via the client (“sft”), such as trying to SSH to a Linux server. The client calls the OPA cloud service to evaluate policy.
- The response includes the access methods (principal accounts and/or a list of vaulted accounts) and any conditions. In this case the condition is an access request.
- The user selects one of the access methods and the client responds to the cloud service to raise the request. The client gets details of the request when it’s been raised (4), returns this to the user session and closes the request.
- The cloud service raises a request in Access Requests.
- The request runs and seeks approval and responds back to the cloud service with an approve or deny. This result is stored in the cloud service.
- The user again requests access to the resource and the client calls the cloud service to evaluate policy.
- The response again shows the access methods, but now shows the previous access method as approved. The user can now select that access method and connect to the resource.
Note that the same flow is used for accessing resources via the OPA web user interface. Also, there will be the normal OPA authentication/authorization steps that we won’t cover here.
Lets walk through an example to show how this works.
User and Reviewer Experience
We start with the user, who uses the client to get a list of servers they can access.
They run a client command to ssh to the opa-demo-linux server. The client contacts the OPA cloud service to evaluate the policy for this user against this server.
The policy determines that the user can access the server with one of two vaulted accounts – pamadmin1 and pamadmin2. Both require approval.
The user selects 1. to connect using the pamadmin1 account. The client contacts the OPA cloud service to initiate the request, responds to the user with the request Id and closes the request.
With the request is raised in Access Requests, the reviewer will get notification via email to go and review the request. They access the inbox in the Access Requests interface to see the new request.
They open the request and can see details of the user, the access type, the account they want to use and the server they want to connect to.
The reviewer can approve or deny the request. In this case they approve it.
The user then retries their server access.
When the policy evaluation is returned, the Approval condition for pamadmin1 is showing as met. They select this access method.
They are connected to the server with the pamadmin1 account.
Now lets look at how this was put together.
Configuration of the Components
Assuming that the Access Requests platform is set up for Privileged Access, we need a Request Type (request flow) in Access Requests for this server access scenario. The following show a simple flow to implement this (if you are not familiar with Request Types in Access Requests, we suggest exploring the articles on the OIG Access Requests page).
This request type has three steps:
- Get approval from the ‘server manager’. This could be a user manager, service owner, a team of approvers etc. There could also be multiple approval steps.
- If the access is approved run an action to tell the OPA cloud service that the request is approved
- If the access is denied, run an action to tell the OPA cloud service that the request is denied
The approval step is standard for Okta Access Requests. The actions in the other two steps are new and unique to OPA.
Note that these actions are tied to a Access Requests team called Privileged Access that is provided by the limited use OPA Access Requests license. They cannot be run by any other teams in Access Requests. If you have both OIG and OPA, you will see two default teams - IT and Privileged Access. You can create other teams, but these two actions are associated with the Okta Privileged Access connection and only the Privileged Access team can be assigned to it.
Now that we have an Request Type, we can assign it to policy in OPA.
Approval requests is a condition on policies. It has two settings – the Request Type to call, and the approval duration (time for the approval to remain valid in OPA).
And that’s it, fairly straightforward – create and publish a request type and assign it to the relevant policy in OPA.
This concludes the discussion of the Access Requests and a PAM Policy Condition use case.
Access Requests to Manage Groups Used in OPA
This is the more traditional Access Requests scenario seen with Okta Identity Governance. Okta Privileged Access (OPA) uses groups pushed from Okta to drive both the administrative roles and policy membership. These can be exposed through Access Requests.
Groups in Okta and OPA
Let’s look at the groups we have assigned to the OPA Team.
There are multiple groups assigned to team roles, but also two groups used in policy: PAM Linux Sysadmins and PAM Windows Sysadmins.
These groups are pushed from Okta groups in Okta.
As these groups are in Okta, we can manage membership via Access Requests. We’ll walk through this…
Creating a Request Type
We have created a Request Type (request flow) in Access Requests for users to select a time-bound access to either the Linux or Windows group.
When run, it will ask the user for a business justification, select either Windows or Linux, and when they need the access until (a date).
The flow will run with a single approver and when approved will add the user to the relevant group in Okta (which will immediately be pushed down to OPA). It will then start a timer to expire on the date selected and on that date it will automatically remove the user from the group.
Requesting Access
When a user runs the request through the Access Requests portal (or via Slack/Teams if that integration is enabled) they are presented with a dialog to enter the required information.
When they submit the request and it is approved, they are added to the the appropriate Okta group and that group change is pushed to OPA. The activity view of the request in Access Requests shows the user added to the Okta group and the timer (for removal) started.
The Okta system log (filtered for that group) shows the user added to the group and the updated group pushed to OPA.
And we can see the user assigned the OPA group in OPA.
They would now be subject to the policies that the PAM Windows Sysadmin group is assigned to.
This is leveraging standard Okta and OIG capabilities – groups assigned to an application (in this case OPA) as push groups, and group memberships managed through Access Requests. Note that this capability (unlke the earlier one) requires an Okta Identity Governance license.
Conclusion
This is a very effective way to manage access to privileged resources. You could have standing privileges (if your risk posture was ok with that) through default Okta groups (perhaps leveraging group rules tied to profile attributes from HR) and requestable/fixed-time additional access managed through Access Requests.
This could be combined with the earlier use case of JIT approval from the client to map access against different levels of privileged access – for example low-risk access by standing access, medium-risk by requestable/fixed-time access, and high-risk a combination of requestable/fixed-time and JIT approval (and other controls). The different integration use cases allow for this flexibility.
