NOTE: This relates to the Request Types interface and does not apply to Resource Centric Access Requests(RCAR/ Conditions and Sequences). For comparison of those, see: Request Types and Resource Centric Access Requests (Conditions and Approval Sequences)
OVERVIEW
This article explores the Timer feature in Okta Identity Governance (OIG) Access Requests. It provides an overview of the 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.
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, a new button labeled “Timer“ should appear at the bottom.
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, that is, pause for a set period of time (N days/hours/minutes).
Or it can End on date, that is, 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 the requester wants to specify a date from some activity. Some examples will be provided later in this article.
In addition to being able to add a timer to a workflow, some of the built-in 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 is assigned to an app, a timer runs (when the assignment step is completed), and the user waits for a day. When the timer ends, the access is automatically removed.
This makes building automated time-bound access workflows very simple. Let us 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, users will be allowed to request access up to a specific date and have it automatically revoked after that date. There will be a carpark access app in Okta that users need to request.
Most of the workflow is a fairly standard access request with an 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 set the end date (like the reviewer).
Manager Setting the End Date for Access
A very effective way of managing access is to let the user select an end date and then have access automatically cleaned up. As shown above, it is possible to let the requester or another user (for example, manager/reviewer, another team, or application owner) set the end date.
NOTE: It is also possible to set a start date (timer between approval and Okta action) or both start and end dates (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 should be cleaned up automatically, such as privileged access. This example uses 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).
On the Assign step ([Okta] Add user to group), the Add a time limit option was selected, and a 2-hour time limit was set.
Add a time limit to the 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 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.
