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.
Please note that this article was written against the Early Access code and may not represent 100% what is available at General Availability.
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, List apps assigned to user and List enrolled MFA for user.
There are some actions to change the status of the Okta user: Unlock user, Activate user, Deactivate user, Suspend user, and Unsuspend user. These can be used to allow a user to self-service.
Finally there are some actions to update the user session and factors: Reset user password, Reset all user MFA, and Clear all user sessions.
Some of these actions are in preparation for the delegated administration (e.g. manager on-behalf of employee) feature to be release later in the year. But many could be used to build self-service workflows. 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.
Example – Suspend Me For A While
The final example is providing users with the ability to suspend all their access in Okta for a while by suspending their Okta user. It leverages the [Okta] Suspend user action as well as the new Timer function (currently available in Oktapreview, production with Limited GA).
The user (requester) is prompted to supply a justification for the request and specify a return date. The workflow will immediately suspend them (you could add a manager approval) and start the timer that runs until the specified date they return to work (“Return date”). On the return date, the user is automatically unsuspended using the [Okta] Unsuspend user action.
The execution of this request is shown in the following three images. First is the questions presented to the requester.
Next we can see the flow execution from the requesters perspective.
Finally we can see the user suspend messages in the System Log in Okta.
After the timer expires, the user is unsuspended. This is shown in the flow execution.
Also we can see the unsuspend event in the Okta System Log.
This concludes the example.
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, managing user state and managing user factors and sessions. This article has explored these and shown three examples of using these additional Okta actions.