Identity Threat Protection with Okta AI will continuously assess user context and automatically respond to identity threats across your ecosystem. This includes managing entity (user) risk levels. Okta Privileged Access does not explicitly have user risk built in, but user risk can be applied to control how users access privileged resources.
This article looks at two scenarios where entity risk can drive access in Okta Privileged Access. The first uses risk-related groups managed by workflow off risk changes and tied to policies in OPA to implement different controls for accessing resources. The second looks at how to drive session revocation in OPA.
The article assumes some knowledge of both Identity Threat Protection with Okta AI and Okta Privileged Access.
This article extends off the Boosting security with Okta Identity Threat Protection and Workflows Okta blog.
Introduction
Identity Threat Protection with Okta AI (ITP) will continuously assess user context and automatically respond to identity threats across your ecosystem. It takes feeds from first- and third-party systems, analyses for session and entity risk, maintains an entity risk level on user profiles and provides mechanisms to remediate those risks. Remediation can include performing universal logout across apps the user is logged into and also running Workflows with bespoke remediation processing.
Okta Privileged Access (OPA) manages and controls access to privileged resources list servers, secrets and SaaS service accounts. It uses policies tied to groups from Okta to determine who can access what and how. Whilst it does not have risk built into the policy engine currently, there are ways that we can influence OPA based on changing risk in ITP.
This article explores two scenarios that have been implemented primarily via Okta Workflows:
- Scenario 1 leverages groups managed in Okta and pushed to OPA. These groups represent different levels of user risk (Low, Medium and High) and in OPA they are mapped to policies and rules with different levels of access controls (none, MFA and Access Requests). Okta Workflows trigger off a change in entity risk (from ITP) and manage the membership of the different groups).
- Scenario 2 is focused on session revocation for both the Okta Dashboard and the OPA session. The latter is managed through removal from the group granting access to OPA in Okta. This is done via Okta Workflows.
The following sections explore both scenarios.
Scenario 1 – ITP Drives Risk-Related Groups and Access in OPA
In this first scenario, we want to apply PAM policy controls based on user risk. The higher the risk of the user the more stringent the controls. In the example below, the user needs to access a Salesforce service account in OPA. If the user is sitting at a low risk level, they will not be prompted for any additional controls to access the credentials for the service account, but if their risk increases to medium, we want to apply MFA, and if their risk goes to high, we want to apply an access request approval.
We will walk though the user experience, then look at how the mechanism is built.
The User Flow
Let’s start with a user, Ivan ITPUser, who is in-scope for ITP risk evaluation.
He is currently sitting at a Low entity risk level, and can access OPA via the OPA Risk All group. He is also in a LOW risk group (OPA Risk LOW) because of that entity risk level.
When Ivan goes to OPA from his Okta Dashboard, he can access the Salesforce SaaS app.
If he goes into the app and selects the service account, he sees he can access it without any special conditions.
But what if something occurs in his session to cause ITP to elevate his entity risk to HIGH?
He now has an Entity risk level of High and he has been moved from the LOW risk group to the HIGH risk group (OPA Risk HIGH).
When he goes to access the same Salesforce account in OPA, he now has an Access Request condition he must comply with before being able to access the account.
If the ITP policy evaluation had resulted in his Entity risk level going to Medium, he would be put into the MEDIUM risk group and would have to meet the MFA condition to access the Salesforce account.
The above is all driven by groups tied to policies in OPA. Lets have a look at how it works.
Overview of the Mechanism
The mechanism involves Okta ITP, Okta Workflows, Okta Privileged Access, users/groups in Universal Directory, and events written to the Okta System Log. The main components are shown in the following figure.
ITP is constantly reevaluating risk based on the events from first- and third-party systems. When a risk is detected there is a user.risk.detect event written to the Okta System Log.
There is a Workflow configured to trigger on the user.risk.detect event. It will evaluate what the user risk change was and move the user between the appropriate risk-related Okta groups.
These groups are assigned to the OPA app as Push Groups, so any change in membership will be pushed to OPA.
In OPA each group is tied to a specific policy that grants access to the Salesforce account. For LOW risk users, there are no controls applied; for MEDIUM risk users there is an MFA control applied; and for HIGH risk users there is an Access Request control applied.
This is an example of how you can use different controls on different levels of risk. You could have different combinations of controls depending on the resource and your policy requirements. For example if accessing servers, you may want to apply session recording to higher levels of risk.
Workflows Configuration
The mechanism uses the (relatively new) Okta ITP connector in Workflows. It comes with a User risk detected event to trigger when a user.risk.detected event is written to the system log.
Prior to the connector, you would have to us an API connector with webhook and strip out the relevant data from the API body. With the event card, the key fields are split out for you.
The data passed in is used to determine the past and current risk level and re-assign risk group membership based on it.
It has the three groups (LOW, MEDIUM and HIGH) hardcoded in a helper flow. It will also check to see if there was an actual change of risk level.
It then uses a series of multi-level if/else statements to remove the user from the old group and add them to the new group. For example, if the user went from LOW to HIGH, they would be removed from the LOW risk group and added to the HIGH risk group.
OPA Push Groups
All three groups are assigned as Push Groups against the OPA app.
Any change in group membership in Okta will flow down to the group membership in OPA.
OPA Policies
As per the figure above, there are three OPA policies to control how the members of the different groups can access the resource (the Salesforce service account). You can see the policies and groups (principals) assigned.
In each policy there is one rule with the appropriate conditional applied. The three rules from the three policies are:
This is a trivial example, but it shows how you can assign users of different levels of risk to different policies. You could potentially have three policies, one for each level of risk and have multiple rules in each for different sets of resources or different resource types. Or you could have multiple policies for each risk-level.
Scenario 2 – ITP Drives Session Revocation in OPA
The previous scenario showed how you could alter access (and controls applied) in OPA based off user (entity) risk changes detected by ITP. But what about if you want to close all sessions if a user’s risk goes to high?
ITP supports a universal logout function where sessions in supported apps can be automatically killed based on policy settings, including the Okta Dashboard the user is using. However OPA does not currently support universal logout. What can we do? We can remove the user from the Okta group(s) that is granting their assignment to OPA. This is a more severe action that killing sessions, but it is a way to reduce that risk (and you could tie in a process to re-add the user to the group, perhaps with an access request and approval).
Note that the mechanism shown below assumes the user is assigned to OPA via a group. If there was a direct assignment the workflows would need to change.
The following shows the user flow and how it works behind the scenes.
The User Flow
We start with our user, Ivan ITPUser, who has logged into his Okta Dashboard and then launched his OPA session to access some credential like in the previous scenario.
At some point during his session, ITP detects a risk and escalates the user risk level to HIGH. All of a sudden his OPA session disappears and is replaced by a Session revoked message.
When he goes back to his Okta Dashboard and refreshes his session he gets a “Your session has expired” message and is taken back to the login prompt.
He has been shut out of both his dashboard and OPA.
He checks his email and sees the following telling him he has lost access to OPA.
The risk change has revoked his Okta session and removed him from the group assigned to OPA, triggering a de-provisioning and session termination.
What’s Going on in the Background?
Let’s have a look at what has happened. Before the detection, the user had an Entity risk level of Low. He had access to the OPA Risk LOW group (from the first scenario) and the OPA Risk All group (which is how he is assigned to the OPA app).
When ITP detects the issue, a series of events are written to the System Log.
From the bottom up you can see the risk detected and (delegated) workflow initiated. There was a universal logout initiated and the user was removed from the group OPA Risk All (this was done in the workflow, we will explore this later). Removing the user from the group triggered a de-provisioning of the user from the OPA app.
Note that the user reverts back to a LOW risk level as the remediation has run, so ITP considers the user risk is back to normal.
Also, whilst the user loses access to OPA, any active SSH/RDP sessions to servers are not immediately impacted, but will be when the agent detects that the account can no longer access OPA.
Okta/ITP Policy Configuration
The ITP policy configuration is straightforward. There is a new rule in the Entity Risk Policy.
This rule applies to all users of the OPA Risk All group. It will run for Admin Reported User Risk events where the Entity risk level is High and will Run a Workflow – OITP – Admin Reported User Risk. The rule was set to just trigger on Admin Reported User Risk as that was how we tested the mechanism. You could have other detections listed.
The bulk of the work is done in the workflow, which we will look at next.
Okta Workflows
There is one main flow (the delegated flow called when ITP detects the risk) and two helper flows.
We will focus on the main flow – OITP – Admin Reported User Risk.
It is called like any other delegated flow, but ITP only passes the Okta User ID for the affected user. It then assigns two static values, one for the app ID of the OPA app in this environment and an administrator email for cc’ing on the email to be sent at the end of the workflow.
Then it uses the ITP Connector Global Token Revocation action to revoke the Okta session token. This handles the Okta Dashboard session revocation.
The remainder of the flow is focused on removing the user for any groups that assigns them to the OPA app.
First it gets all groups assigned to the user in Okta; uses a helper flow to reduce that list down to the group ID, name and description; and then pulls out just the IDs (a list of text).
Next it finds all the groups assigned to the OPA app and plucks out the IDs for them.
We now have a list of IDs for the groups assigned to the user, and a list of IDs for the groups assigned to the OPA app. The intersection of these two lists are the groups that map this user to the OPA app. Note that there may be more than one groups granting access to OPA.
A helper flow will process each of the matching groups in turn. It will remove the user from the group using the Okta connector action and then format that group into a HTML list item for the email to be sent.
Finally it will get some user properties, then build and send an email to the user informing them of the groups they have been removed from.
This concludes the exploration of the second scenario.
Conclusion
This article has shown two scenarios for using entity risk derived by Identity Threat Protection with Okta AI to control access into Okta Privileged Access.
The first scenario leveraged risk-related groups pushed from Okta to Okta Privileged Access and assigned to different policies and rules to implement different controls on accessing resources. You might say that low risk users can access a resource with no additional checks, but medium risk users will need to meet a MFA requirement or high risk users will need to get the access request approved before accessing the resource.
The second scenario leverages extend the Identity Threat Protection with Okta AI universal logout remediation to remove a users Okta Privileged Access session by removing them from the group(s) granting them access to the app.
Both scenarios are implemented using Okta Workflows, and the article shows how they are implemented. They could form the basis of custom implementations in your environment.
Download
The workflows package for the flows in the article can be downloaded below.
One thought on “Using Risk in Okta to Manage Privileged Access in OPA”