OIG Access Requests – Using the New Timer Feature

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

New Timer function in Access Requests

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.

Timer step in workflow

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.

Need Until step using 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.

Access Request Workflow with Timer and Revoke steps

When this flow runs, the requester will need to select the date they need access until.

User initiates access request

When the workflow is approved and the app is assigned in Okta, the timer will kick in.

Timer running in workflow

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.

Manager Setting the End Date for Access

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.

Add a time limit to Group Assignment

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).

Timer and Revoke steps in Workflow

When the access is requested, and after the approval (Review) and group assignment (Assign) steps run, the Timer for two hours is triggered.

Timer for 2 Hours

Hovering over the message in the Tasks view shows the actual time of expiry.

This group membership is automatically removed after two hours.

Timer done and access revoked

The actions are reflected in the Okta system log.

System Log entries for workflow actions

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.

Leave a Reply