Admin role-centric access certification campaigns enable organizations to align access privileges with the principle of least privilege, granting users only the necessary access required to fulfill their responsibilities. This approach minimizes the risk of unauthorized access, insider threats, and data breaches, as access permissions are tailored to each individual's role and responsibilities. This approach also opens the door to security-based governance using events to trigger user-based campaigns reactively.

To deliver the most impactful access certification reviews for an organization’s most sensitive resources, having the ability to review at the user level is a security must. Here is how to create those User Campaigns with OIG.

• Access Certifications

This short post is for the information of people who may look at some of the older OIG API and Workflows articles on this site and find they no longer work. Use the Okta Connector with the Custom API Action card now instead of the old generic API Connector card.

1. The OLD Way to Use OIG APIs in Workflows
2. The NEW Way to Use OIG APIs in Workflows
3. Enable Okta API Scopes in Okta Workflows OAuth App
4. Use the Okta Connector with Custom API Action in Workflows

The OLD Way to Use OIG APIs in Workflows

In the first articles written on how to extend Okta Identity Governance (OIG) with APIs and Workflows, the Okta Workflows OAuth app had not been updated to include the OIG API scopes. This meant that it was necessary to use the generic API Connector.

The following figure is an example of this:

The flow shown here is fairly standard:

1. Set up the Authorization object (SWSS <token>) using a sub flow with a token tied to an admin user in Okta
2. Set up the URL for the generic API call, which includes https:// and the Okta org domain name, with the API endpoint relative URL
3. Construct a query object and/or body object depending on the needs of the API
4. Call the API Connector card passing in the full URL, query/body objects, and the authorization object

The key here is setting up the authorization object and the full URL.

The NEW Way to Use OIG APIs in Workflows

The Okta Workflow OAuth app was recently updated to include the governance scopes. Using the old method may result in workflows failing with a 401 Unauthorized error (errorCode “E0000011” errorSummary “Invalid token provided”). This is an indication that flows need to be updated to use the Okta Connector with the Custom API Action card.

There are two things to be done: enable the relevant scopes for the app and update the flows.

Enable Okta API Scopes in Okta Workflows OAuth App

First, there are multiple Okta API Scopes that can be granted in the Okta Workflows OAuth app. They are fairly generic – read or manage for the three types of functions (access certs, access requests, and entitlements).

Grant the level of access to the API calls needed in the workflows.

After updating the scopes in the app, re-authenticate the connection in Workflows.

NOTE: There is only one OAuth app, so it is necessary to grant the highest level of access to cover any API call made across all of the workflows, and any workflow could use higher-level permissions than necessary. Apply controls around who is building flows and what APIs they are including in the flows.

Use the Okta Connector with Custom API Action in Workflows

With the scopes granted, the flows can be updated to use the Custom API Action card from the Okta Connector.

Here is the flow from above, but changed to use the new method.

Changes from the old approach:

• It is no longer need to use an API token and set up the authorization object – the Okta connector handles this
• The URL passed into a Custom API Action card is the relative URL (for example, /governance/api/v1/requests), not the full URL
• The query/body arguments are the same.

The output is the same for both (Status Code, Headers, and Body), so the processing of the response won’t change.

This approach is much cleaner. It is not necessary to store an API token somewhere (like in a table or hardcoded into a flow) and there is no need to worry about updating the token when it expires. Additionally, the okta URL is tied to the connector, making the flows more portable.

Related References

• Automate with Okta Identity Governance APIs
• Guide on using the Okta Identity Governance APIs
• Introducing “Request on Behalf of” for Okta Identity Governance