If you were at Oktane22, or have listened to the Oktane22 roadmap sessions, you will know risk and use of risk signals is a key focus for Okta going forward. This includes leveraging risk in Okta Identity Governance (OIG), to help make access requests and access certification more effective.
But can you leverage risk today? Yes. A common ask is for risk-based certification campaigns. We don’t have the ability to add some risk indicator to an application object in Universal Directory and leverage that in OIG Access Certification. However we can make use of Okta Workflows and the OIG API (currently in beta) to achieve the same thing. This article explores how this could be implemented.
Overview
The desired outcome for this sample implementation is to run a certification campaign for all user assignments to all “high” risk applications, such as shown below.
The solution uses an application list stored in an Okta Workflows table that has all Okta apps listed and a risk rating (in this case “High”, “Med” or “Low”) assigned. You could use any approach to risk ratings.
Then a Workflow runs through to extract all the “High” risk applications, build the components (body and header) for an OIG API call to create the campaign, then do the same to launch the campaign.
As you will see below this was a fairly straightforward implementation. As I already had a set of workflows to create a campaign, this only took about an hour to build and test. When we get to the point of having the OIG APIs baked into the Okta Connector in Workflows, this will be even simpler.
Components
The solution was implemented using Okta Workflows – two tables and a set of workflows.
The tables are: Environment Variables to store the apiToken and other variables used in the flows, and Applications to store the application list.
There are three sets of flows:
- M1* – Flows to populate the Applications table
- M5* – Flows to create and launch the campaign
- U0* – Shared utility flows
The next sections describe the components and use.
Building and Storing Application Risk
The first step is to populate a workflows table with all the applications defined to Okta. The M1* flows do this. Once the list is populated, an administrator would go through and assign a risk level to each application.
Each time you run the M10 flow, it wipes the application table. If you were implementing this in a production system, you would probably make it more of an add/update mechanism so you don’t lose existing risk assignments.
For the second step (below), we only need the risk rating and resourceId (Okta application Id) – the other fields are just for the info of the admin setting the risk rating.
Creating and Launching a Risk-Based Campaign
The second set of flows will use the applications table to pull all “high” risk applications and use them to create and launch a campaign.
The main flow (M50) will setup some common variables (Okta domain for API URL construction, and the authorization object) then:
- Run a subflow (M51) to extract all application table rows where “Risk Rating” = “High” and return a list with a single object of resourceId (the Okta application id). Not coincidentally, the “resourceId” label is used in the OIG API call, so there is no reformatting of the object required.
- Run a subflow (M52) to build all the parts of the API call to create a campaign, put them together in a body object then make the API call to create the campaign.
- With the returned campaignLaunchURL, build and run an API call to launch the same campaign (M53).
I won’t go into depth with the actual workflow steps. A very similar set of flows is explored in https://iamse.blog/2022/10/27/oig-certification-for-external-system-entitlements/.
The end result is a campaign with all the users assigned to the high risk applications.
Of course the flows could be modified to have different settings on the campaign.
That’s it, pretty simple and easy to implement.
Conclusion
This article has shown a sample implementation of how a risk-based application access certification campaign could be implemented using Okta Identity Governance, Okta Workflows and the OIG API. It is a fairly simple implementation that is easy to build.
