The Okta Identity Governance (OIG) Access Requests module is built for requesting (and reviewing/approving) access to applications or groups in Okta. However, the module can do a lot more with the actions provided for the Okta integration. This article explores these and gives some examples of how they can be used.
Article contents:
Please note that an earlier version of this article included Okta actions that have been removed.
Okta Actions Available In Access Requests
The Okta integration with OIG Access Requests provides a number of actions (using Okta API calls) into Okta. The standard actions used for requesting access are Assign individual app to user and Add user to a group. These will be the latter part of an access request workflow where the user has initiated the request, supplied some information (like a justification) and some form of approval has run.
But there are more actions available to interact with Okta.
In addition to adding a user to an entitlement (group or app), you can also run a flow to remove the user from an entitlement (Remove user from a group and Remove user from app). These may be combined with a Timer (another new features) to provide time-bound access.
There are some actions that will query information in Okta and display the results in the request history: List groups assigned to user, List groups assigned to app, and List apps assigned to user.
We will look at some examples in the following sections.
Example – List All My Apps
As a user, you can see the applications you’re assigned to in the Okta Dashboard, so the following example may not be that useful. But the approach applies for all four of the “[Okta] List ***” actions and shows how you can use the actions.
The actions have been written with privacy in mind, so that the results of the action (i.e. the requested list) will only be shown to the workflow owner (assignee, such as the IT admin administering the processes). So, they will need to copy the results to the chat/flow to make the results available to the requester.
Let’s start with a simple flow. It has a single action to run the [Okta] List apps assigned to user action.
When the flow is executed, it runs the Okta action to retrieve the data. The following is what the requester sees.
The action returns the list of applications to the flow, visible to the flow owner. The following is what the assignee (owner of the flow) sees.
The flow owner can copy the resulting text (the list of apps) into a message for the flow so it is visible to the requester. The following is the view for the requester.
This example shows how this information can be presented back to the user. Obviously this is just the beginning with these actions – there is a lot of scope to expand on use of the returned data in Access Request workflows, such as providing context to a reviewer before approving an access request or providing a personalised list.
Example – Remove Me From an Application
An ask I had recently from a customer was for users to be able to request removal of an application via self-service. We can easily do this with Access Requests using the [Okta] Remove user from app action (or the [Okta] Remove user from a group action for group/role membership). The following is a simple flow for removing a specific app selected by the requester.
The [Okta] Remove user from app action requires an application to be specified. In this example, it’s the application selected from the Application dropdown list.
The flow will run and automatically remove the user from the selected app.
The result is shown in the Okta System Log.
This is a trivial example to show the basic mechanics.
Conclusion
In addition to the access request actions for group membership and application assignment, there are a number of other actions available from OIG Access Requests into Okta, such as listing entitlement information. This article has explored these and has shown two examples of using these additional Okta actions.
