A common ask for Okta Identity Governance is to be able to log at ticket in a service desk tool, like ServiceNow, for manual provisioning activities after following an approval process in Access Requests. This article explores one approach to this using OIG Access Request events in the Okta System Log, Event Hooks and Okta Workflows.
Overview
This solution is an example of how Okta Workflows can be used to log a request in ServiceNow. Whilst there are other examples of this around, this one is specifically tied to Okta Identity Governance (OIG) Access Requests.
It is a one-way flow from OIG Access Requests, through Okta to Okta Workflows and ServiceNow as shown below.
The steps are:
- A user requests access to a resource (like an app) in OIG Access Requests,
- The completion of the flow for this access request writes an new event into the Okta System Log,
- An Event Hook in Okta will trigger on this event and call an Okta Workflow,
- The Workflow will collect the event data, enrich it, then log the request in ServiceNow.
The remainder of this article will show how this works and how it was implemented.
This is only one approach, you can also log a ticket directly from the Access Request flow, but you have no control over the data sent to ServiceNow or any formatting of that data. See https://iamse.blog/2022/07/06/integrating-servicenow-with-oig-access-requests/.
Executing the Use Case
The use case starts with a user requesting access via the WebUI in Okta Access Requests.
This can be any request with any approval and other steps. In this case it’s using a dummy (bookmark) app in Okta. The user supplies answers to the questions and submits the request.
Once any approvals are completed, actions are run and the request is closed, as shown on the administrators view below.
Note the highlighted information in the request, like the questions, approvals and actions. This will be leveraged in the ServiceNow request (ignore the second action to log a ticket in ServiceNow – that was just done for comparison).
When the request is closed, an access.request.resolve event is written into the Okta System Log for this request.
Within Okta, an Event Hook is configured to call an Okta Workflow via an API Endpoint. This triggers the workflow which extracts the event data, enriches it and writes a new request into ServiceNow.
The request in ServiceNow contains some of the standard fields (and you can specify which fields to set). Notice the formatting in the Description, Short description and Special instructions fields. These have been built in the workflow based on data passed in the event, an API Call to the request, and Okta user profile lookups.
Now let’s look at how the pieces are put together.
Exploring the Configuration
The main sections of the flow are:
- OIG Access Requests to Okta System Log
- System Log Events and Event Hook,
- Okta Workflow to write to ServiceNow
These are detailed below.
OIG Access Requests to Okta System Log
Any request will log events in the Okta System Log. For example, if the request is adding a user to a group you will get an event for that. Two new OIG-specific events have been added recently – access.request.create when a request is created (user clicks submit) and access.request.resolve when the request is marked as completed. These new events provide a richer set of data than the standard group membership and application assignment events.
It is worth noting that the access.request.resolve event will only trigger when the access request is marked as done. If you have a flow that grants access, runs a timer, then removes access, the event will not be written until the last action (remove access) is run.
Every OIG access request will create these events in the syslog, so if you don’t want Workflows processing them all, you will need to apply Event Hook filtering or code some checks into the flows.
System Log Events and Event Hook
Whilst we’ve had group and application events from OIG Access Requests, the new events provide more information about the request, specifically in the DebugData and Target objects as shown below.
The DebugData contains a lot of information about the requester, request, and owner. The Target contains the type (“ACCESS_REQUEST”) and request name which can be used in an Event Hook Filter.
To trigger a workflow from this event, you need to create an Event Hook that uses the Invoke URL of the API Endpoint card of the workflow (see below). The event hook could be listening for access.request.create events, access.request.resolve events or both. Given that the important data (like approvals) won’t be available until the end, I have used the access.request.resolve event only.
If you don’t want every access request to trigger the workflow, you can use the new Event Hook Filtering mechanism. An example is shown below that leverages the new Target object discussed above.
If you want to explore the Event Hook Filtering mechanism, see https://iamse.blog/2022/07/12/event-hook-filtering-and-okta-workflows/.
Okta Workflow to Write to ServiceNow
A single main workflow, with some utility flows, is used and described below.
The flow has an API Endpoint card to trigger it. The Invoke URL field is used in the Event Hook above. Note that the alias/client token values are not populated until the flow is enabled/saved.
The first card in the flow is an API Connector:Close card. This is so the Event Hook does not timeout and retry causing duplicate executions.
The next three cards are extracting the relevant values from the event body, specifically the data.events.0.debugContect.debugData object and the data.events.0.actor object. Note that there is only ever one events object, thus the [0] reference. The debugData attributes are the most interesting and shown below. They include the Okta Id’s for the requester and owner as well as information about the request.
In this flow, I checked if the event was for a specific OIG request type. But you could use Event Hook Filtering as mentioned earlier.
We go off and read the Okta user profile for the requester to collect some information. This is formatted into a text value that will be used in the Special Instructions field of the ServiceNow request. This is just an example – you could use anything.
The next step uses the requestId from the event body debugData. It calls a subflow that will use an OIG API (currently in beta) to get the request object.
Out of this request object, the questions (requesterFieldValues), approvals and actions lists are extracted.
It checks for any approval steps that were NOT approved and continues if none were found. We don’t want to log a ServiceNow request is it wasn’t approved, and this is the earliest in the flow we can check it.
For each of the questions, approvals and actions, we strip out and format the key information using subflows and then write the resulting strings into a single field that will be used as the (long) description.
A short description is composed. Then all of these are used to create the request using the ServiceNow:Create Request card.
Again, this is just an example of the fields populated in ServiceNow from the workflow – there are many more that could be used, particularly when you have an established ServiceNow deployment with standards and processes.
Conclusion
You can use a combination of Okta Identity Governance Access Requests and Okta Workflows to create a request in ServiceNow. This is useful where you need to log a ticket for manual processing, but want all access requests to run through OIG Access Requests.
This article has shown the design of the solution, a sample execution and the components configured to implement the example. Hopefully this will help readers implement similar mechanisms.
