This article explores the new Timer feature in Okta Identity Governance (OIG) Access Requests. It provides an overview of the new function and how it could be used for a long-term (days or weeks) access request and a short-term (hours) privileged access request.
This article assumes a familiarity with the OIG Access Requests workflows. For more articles see https://iamse.blog/identity-governance-and-administration-iga/oig-access-requests/.
At the time of publishing this article, the Timer feature is only available in preview environments, but will be in production with OIG General Availability (Aug timeframe).
Overview of the new Timer feature
This new feature allows an Access Request workflow to be paused for a period of time, or until a certain date.
When accessing the workflow builder view, you will see a new button at the bottom, labeled “Timer“
Clicking this will add a new Timer step to a workflow. It will pause the execution of a flow and then continue the flow after the timer ends.
It can “End after duration“, i.e. pause for a set period of time (N days/hours/minutes). Or it can “End on date“, i.e. pause until a specific date (based on a previously selected date field). The former is great for fixed, short term breaks in a flow. The latter is better when you want the requester to specify a date from some activity. We will provide some examples later in this article.
In addition to being able to add a timer to a workflow, some of the inbuilt actions have a timer function added with an “Add a time limit” option.
Selecting this allows setting the same Timer settings (“End after duration” or “End on date”) as the Timer function above, and will add a Timer step to the flow.
It will also automatically add the reversal action. If the action was “[Okta] Assign individual app“, then a new “[Okta] Remove individual from app” action is added. Both steps have the appropriate Logic added so they will only run based on previous steps.
In the example above, the user will be assigned to an app, a timer will then run (when the assignment step is completed) and wait for a day, then when the timer ends, the access is automatically removed.
This makes building automated time-bound access workflows very simple. Let’s look at two examples, a longer-term app assignment and a short-term privileged access assignment.
Example 1 – A Date-Select Long-Term Assignment
In this example, we want to allow users to request an access up to a specific date and have the access automatically revoked after that date. For this example, we have a carpark access app in Okta that users need to request.
Most of the workflow is a fairly standard access request with approval flow. But an additional question is asked “Need Until“, which is a Date question.
With the Assign to App action, I have selected the Add a time limit and set it to the date selected by the requester.
When this flow runs, the requester will need to select the date they need access until.
When the workflow is approved and the app is assigned in Okta, the timer will kick in.
Once the Timer ends (at midnight 30 June) the app access will be automatically revoked.
A variation on this would be to let someone else, like the reviewer, to set the end date.
Letting the user select and end date, and then having access automatically cleaned up, is a very effective way of managing access. As shown above, you could let the requester or another user (e.g. manager/reviewer, another team, application owner) set the end date.
Note that you could also set a start date (timer between approval and Okta action) or both start and end date (two timers, one before the Okta provision action, and one before the de-provision action).
Example 2 – A Fixed-Time Short-Term Assignment
This example is for a fixed-time access set in the workflow itself. This approach lends itself to short term access that you want cleaned up automatically, such as privileged access. In this example we will use a request to access a set of Windows DBA accounts (that would be tied to the Okta Advanced Server Access AD-Joined feature, so the user can select which accounts they want to access a Windows server as).
On the Assign step ([Okta] Add user to group) the Add a time limit option was selected and a 2 hour time was set.
This added two additional steps – the Timer to wait 2 hours, and a Revoke step to take the user back out of the DBA access group (using the [Okta] Remove user from a group action).
When the access is requested, and after the approval (Review) and group assignment (Assign) steps run, the Timer for two hours is triggered.
Hovering over the message in the Tasks view shows the actual time of expiry.
This group membership is automatically removed after two hours.
The actions are reflected in the Okta system log.
This is a basic example of implementing automated short-term access, such as for privileged access.
Conclusion
The new Timer feature in Okta Identity Governance Access Requests opens up new use cases, such as time-based automatic revocation of access granted.
This article has described the new feature and shown two examples of this automatic revocation. The first is for a date-bound automatic revocation, where the requester (or another person) selects an end-date for an access and Access Requests will automatically remove the access on that date. The second shows a time-bound revocation where access is automatically revoked after a fixed time interval, which would be very useful in privileged access requests.
One thought on “OIG Access Requests – Using the New Timer Feature”