Overview

While using Access Certification, we often encounter the question of how to streamline the remediation process for a disconnected application. Since there is no direct connection between Okta Identity Governance (OIG) and the application, and if the reviewer chooses a Revoke decision for a user, how can this decision be implemented or reflected in the end application? In this article, we will discuss an approach to how Workflows and ServiceNow can be leveraged to achieve a solution for such a scenario.

Solution

A solution for this scenario can be achieved using Okta Workflows with OIG, which will log a ticket in ServiceNow, and then this ticket can be used to update the user assignment in the end application. The sequence of this whole operation will be as follows:

1. Access Campaign for the disconnected application is launched.

2. The reviewer submits the decision on the access review assigned.

3. Once the Access Certification decision is submitted, this event will trigger the Workflow.

4. The Workflow will collect the event data for the Revoke Decision and then create a ticket in ServiceNow.

Requirements

1. Okta Workflows

2. Configure ServiceNow connection in Workflows Console. (Refer to this documentation.)

After understanding how this solution will work, let us dive into how to create the workflow needed for this functionality. The workflow needed for this solution has to be invoked using an Okta Event, which is Access Certification Decision Submitted. 

This event will fetch all the details related to this particular event from Okta and present them in the event output, but only Debug Data from the Debug Context section will be used for this flow. Debug Data contains crucial information about the campaign and its associated items, but only some of the data is to be used. In order to extract the required data, a Get Multiple Object card will be used. Using this, we can fetch and use each of the data points separately.

The data points to be fetched and used are as follows:

1. campaignItemPrincipalId
   It is the Object ID of the user for whom the access review decision has been submitted.

2. campaignItemDecision
   It conveys the Decision taken for the access review, which may be APPROVE or REVOKE or UNREVIEWED

3. campaignTemplateName
   It is the name of the access certification campaign to which this access review belongs.

4. campaignItemReviewerId
   It is the Object ID of the reviewer who has reviewed the access and submitted the decision.

5. campaignItemResourceName
   It is the name of the resource against which the campaign has been executed.

6. campaignItemDecisionNotes (Optional)
   These are the justifications provided by the reviewer while submitting the decision. It is only available if Justification for Reviewer has been enabled.

The Automatic Remediation for an Access Review will only arise when the reviewer chooses to Revoke the access of the user. So, to filter out only the Access Certification Decision Submitted event that has a Revoke Decision, we will be using the Continue If card. This card will allow the Workflow to continue only if the said condition is True, else it will stop the workflow.

Now, once we have filtered out the Revoke-based Access Certification event, we will fetch the details of the User for whom the access certification decision was submitted as well as the details of the reviewer. This can be achieved using the Okta Read User card. The campaignItemPrincipalId and campaignItemReviewerId will be used as input to each of these cards to fetch the details of the User and the Reviewer.

The output from the Read User card will be used to articulate the message to be fed into the ServiceNow ticket. A Compose card will be used to create the Description, using the User’s attributes such as First Name, Last Name, campaignItemResourceName, Username, Email and ManagerId. Also, we will be using one more Compose card to formulate a Short Description which will be used for the title of the ServiceNow ticket.

NOTE: These attributes are only shown as a standard for this example. Depending on the requirement, more attributes can be added to the card.

When the Description and Short Description are ready, we will use the App Action button and select the ServiceNow app, which in turn will present all the actions available with it. From the options, we will select the Create Request action. Select the options Requested for, Description, and Short Description from the list of available options and Save. 

Once the ServiceNow Create Request card is ready, map the outputs of the Compose cards to Description and Short Description respectively. Also, the Username is mapped from the Okta Read User card. 

Save the Workflow with a suitable name and switch on the flow using the On/Off button. 

Now, whenever there is an access review decision submitted in Okta Identity Governance, this workflow will be invoked, but it will only execute when the decision submitted is Revoke. For a Revoke decision submitted, it will create a request ticket in ServiceNow.

RELATED REFERENCES

• Call a Workflow from a Request Type or Condition

• Guide on using Okta Identity Governance API’s

• Okta ServiceNow Workflow Connector