A common requirement for Identity Governance and Administration (IGA) controls is for reassignment when a reviewer, like a manager, goes on leave. Okta Identity Governance (OIG) currently supports manual reassignment of access certification reviews by an administrator or by the reviewer themselves.
But what about automatic reassignment based on a change to the user profile, such as from a feed from a HR system? OIG does not currently support this out-of-the-box, but can do so using Okta Workflows with the OIG APIs. This article shows an example of this and could be used as a basis for a tactical solution before it is available in the product.
The code for this sample solution can be downloaded here (github).
Note – at the time of writing this the OIG APIs were in beta.
Overview
As mentioned above, this solution implements an automated manager reassignment in active Access Certification campaigns where the reviewer is the manager. It is based on two assumptions:
- That Access Certification campaigns will be launched regularly with the users manager (using the managerId field in the Okta user profile) as the reviewer
- Some process is maintaining specific (custom) reassign fields in the same user profile
The solution and it’s context is shown in the figure below:
In it a campaign is launched with the reviewer being the users manager. At some time after a campaign is launched, there is a feed from a HR system setting a temporary manager for the user, with a start and end date for the reassignment.
Periodically (perhaps daily) an Okta workflow runs to get all users with active reassignment values set (i.e. between start and end dates) and stores them in an Okta workflow table. This was done to allow for build/test, as well as for future re-use of the flows for access request reassignment. Then a second set of flows runs to find all active campaigns, find all unique manager reassignments, then go through the active campaigns and reassign to the appropriate new managers. It can run for multiple active campaigns, and for multiple user reassignments. Details in the following section.
After the second set of workflows run, the reviews for the affected users have been reassigned to the temporary manager.
Reassigning Managers
This section of the article walks through an execution of this solution.
Campaign Launched
The first step in testing this was to launch a campaign against a resource including some users who will have their managers reassigned. In this case I setup a test group (“Test Reassign”).
You can see three users with a manager of Frank Grimes.
Manager Reassignment from HR (or other)
The solution is based on three new (custom) attributes added to the Okta user profile
- A Reassign Start Date (reassignStartDate) in the form YYYY-MM-DD
- A Reassign Temp Manager (reassignTempManager) with the username of the new (temp) manager
- A Reassign Stop Date (reassignStopDate) in the form YYYY-MM-DD
Some of the workflows look for these specific fields, and expect the data to be in the specific format.
In a real deployment these fields would be automatically populated, perhaps from a HR feed, and massaged in the profile mapping. But for the sake of this test, I set the fields directly in the user profile for the three users shown above.
Workflow Execution
With an active campaign, and three users with reassigned managers, I ran the workflows (see details below) to find all users with temp managers assigned, store them in a Workflows table, find all active campaigns, find the unique manager reassignments and update the unprocessed certification reviews.
For the test I ran them manually, but you would schedule them to run daily. They would be run periodically to catch any new campaigns launched since the last execution (as the campaigns would be looking at the standard managerId field, not the new one).
Results
As a result of the execution of the workflows. the reviewers have been reassigned to the new manager (in this case Monty Burns).
If the workflows were rerun before any other campaigns were launched, they would not find any reviews assigned to the old manager (Frank Grimes).
The flows only assign the new manager within the reassignment window. They do not revert back to the original manager after the reassign period ends (although it could as easily be done in Workflows).
Understanding the Flows
The main focus of this article is on the Okta Workflows components used to implement the solution. As with all Workflows solutions, it uses both Tables and Flows. The flows are shown below.
The following sections briefly describe the tables and flows.
Tables
There are three tables used by the workflows:
- Environment Variables – this table stores the variables used by the flows, such as the API token to make the OIG API calls
- User Managers – this table is used if the R10 flow is run to identify all users with managers (managerId) specified in Okta. It is not used by the main flows.
- User Reassignments – this is the main table used between the first set of main flows and the second set.
The User Reassignments table is storing each user that has an active manager reassignment (i.e. date run is between the start and end dates). It’s storing information from Okta about the user, the regular manager and the new (temp) manager. Data held includes the Id, username and fullname. Also the reassignStart and End dates are stored.
The tables will be mentioned below.
Main Flows
There are two sets of main flows – the M0* flows to get active reassigned users, and the M1* flows to reassign reviews.
The M00 flow will create a search argument for the current date being between the reassignStartDate and reassignStopDate. It uses this search argument with an Okta List Users with Search card. The returned users are streamed to the M00a flow. Thus subflow will extract the user data, lookup the manager and new manager IDs, reformat the reassign dates and store the records in the User Reassignments table.
The M10 flow will perform the review reassignment. It builds the API authorisation header and gets the Okta domain (both using utility flows), gets all active campaigns and stores them in an object (with the M11 flow), strips out a unique list of managers/new managers from the object (there is an assumption that a manager will only ever be reassigned to a single new manager), then for each unique manager/new manager pair, it uses the M10a flow to process it.
For each manager/new manager pair, M10a the review data, then builds and uses the M12 flow for each active campaign. The M12 flow then builds and runs the OIG API calls to get the relevant reviews and reassign them.
Most of the workflows use standard workflows functions and Okta connector actions. However there are examples of using OIG API calls:
- Call to list all campaigns and filter for only the active ones – in M11
- Call to list all reviews with a specific reviewerId and campaignId and filter for only the unreviewed ones – in M12
- Call to reassign reviews to the new reviewer (this was straightforward as the reviews call returns the reassign URL) – in M12
These could be used as examples of how to make OIG API calls.
Report Flows
The R10 flow will list all users and their assigned manager. It reads all users in the Okta instance, streams each one to the R10a flow to get the manager and writes out the user and manager userids. This is not intended to be regularly run – it’s a tool to assist testing.
Utility Flows
There are a number of utility flows, some that I use regularly:
- U00 – Get AuthZ Header – this builds the authorization header for API calls
- U01 – Get one env variable – this reads the Environment Variables table to get one specific environment variable based on a key passed in (like the Okta domain)
- U02 – Get User Name – builds a username from either a fullname or first + last name
- U03 – YYYYMMDD to Standard Date – for date conversion
This concludes the discussion of workflows components.
Conclusion
Whilst Okta Identity Governance (OIG) supports manual reassignment of reviewers, it doesn’t yet support an automated mechanism. However, as this article has shown, you can easily build a solution and implement it by extending the Okta user profile and Okta Workflows leveraging the OIG APIs.
