Okta recently released a Workflows connector for Okta Privileged Access. It provides an abstraction of many of the Okta Privileged Access APIs to make working with them in Workflows easier.
This article is an exploration of using the new connector to produce Okta Privileged Access reports, specifically access reports for users and resources.
Introduction
Okta Privileged Access (OPA) has a reporting capability exposed through the Access Reports API. The reporting mechanism is asynchronous where you would request a report to be created, check to see if the report is ready to be downloaded, and then download the report in a CSV formatted block of text. Up until the Workflows Connector was released, you would need to establish the appropriate credentials and run the API calls directly.
The new Workflows Okta Privileged Access Connector handles all of the authentication for the API calls and abstracts the API calls. There are action cards to Create Access Report, Retrieve Access Report, and Download Access Report. As the create report API requires IDs (like a userID and serverID), there are also actions to Find Users, and Find Servers. These will take any string and search for OPA users or servers that match and return a list of users/servers (including IDs) that you can interrogate to get a specific ID to report on. The different actions provided gives you a lot of flexibility in how you build your flows.
This article provides an example pair of flows, one to produce a User Access Report and one to produce a Server Access Report. As we walk through the examples, we will show how the different actions listed above are used.
Overview
For this article, two Workflow flows have been built that will consume a search argument (user or server), generate and download the report using the APIs, then email the report CSV to a user. The two flows are exposed as Delegated flows. This means there is no need for the person who needs to run the report to go into the Okta Workflows UI, they can run them (if they have the access) from within the Okta Admin Console.
The two delegated flows are shown below.
Let’s run through the User Access Report flow. Clicking Run beside the report produces a dialog box prompting for any arguments to be passed to the calling flow. In this case we’re passing a search string for a user in OPA.
Clicking Run submits the flow, and you get a confirmation message.
After the flow completes, an email is received with the report attached.
Opening the report file we can see the details of the user, the resource, and the policies available. These show the account the user can use (shared, such as root, or individual), the privileges for that user (user, sudo or admin) and any conditions on using that account (like MFA, Approval, Gateway and Session Recording).
The mechanism for the Server Access Report is exactly the same, just that the resultant report is focused on all access to a specific resource.
Now that we’ve seen the inputs and outputs of the reporting mechanism, we will dig into the implementation in Workflows.
Construction of the Flows
To implement this we needed:
- An Okta Privileged Access connector, an Okta connector and an Email connector (in this case GMail), and
- A set of workflows (delegated and helper flows) to implement the processes.
The flows are shown below.
We will explore the Okta Privileged Access connector and the flows in the following sections.
Creating a Connection
The steps to create and authorize a new connection are detailed here. You could create a service user in Okta (with super admin rights) and assign it to the Okta Privileged Access application so the Workflows connection will use it.
To create the connection you will need a service user in Okta Privileged Access and that service user will need to have administrator roles in Okta Privileged Access (currently it needs Resource Administrator and Security Policy Administrator, but may need PAM Administrator in the future if user/group management functions are added). This is because the APIs used involve working with most of the data objects in OPA.
In this case we have created a service user called workflows-connector and created the API Key for them.
When creating the connection you will need to specify:
- The Name of the connection and a Description (optional),
- The Okta Privileged Access Team Name (this would be in the URL,
https://<team>.pam.okta.comorhttps://<team>.pam.oktapreview.com), - The API Key ID and Key for the service account, and
- The Okta Privileged Access Base URL
The base URL should not have a trailing /. An example is shown below.
With this configured the Workflows can leverage the Okta Privileged Access actions.
The Delegated (Top-level) Flows to Create and Download the Reports
There are two delegated flows, one for the user access report and one for the server access report. Both have the same structure:
- Check a search string has been passed in and call a sub-flow to find the ID of the user / server that matches the query and create the report.
- Use a sub-flow to check if the report is ready to be downloaded, and if not, wait a bit and retry
- Check if the completed report is empty and if so, end the flow
- Use a sub-flow to download the report
- Extract the CSV formatted report and store in a Workflows table
- Export the table to a CSV file and email it to the user who requested the report
The following screen shots show this for the Server Access Report. The input card is the Delegated Flow card and it is consuming the search string (server search string in this case). It checks that the search string is non-blank then calls the S20 sub-flow to find that server and generate the report.
The next section will wait for five seconds and then use a sub-flow (S50) to get the details of the report, including it’s status. The status should be COMPLETED or COMPLETED_BUT_EMPTY to proceed.
If it doesn’t have one of those two statuses, there is another wait of 15 seconds the the process is repeated.
Note that this is a very inelegant way of implementing what should be a do-until loop. You could create a sub-flow that is called recursively and breaks out (return) when the status is COMPLETED).
If the status is COMPLETED_BUT_EMPTY it will end the flow with a message saying it’s empty. If not, it will call a sub-flow (S60) to download the report and then split up the CSV Report text block into a list (with a carriage return as the separator).
We want to store the report in a Workflows table because Workflows isn’t great at processing CSV blobs of text. To do this we first empty out the report table and then call a sub-flow (S80) to parse out the field in each CSV row and store them in a table. This table is then exported as a CSV file (note that it was a Workflows text field, now it’s a Workflows file).
The last section will lookup the user who initiated the delegated flow to get their email address(es) and these are used to send an email with the report CSV file.
This completes the two delegated flows.
The Sub-flows Used
Whilst there are six sub-flows listed above, we will focus on the three that use the Workflows Connector actions: S10, S50 and S60.
The first is the S10 – Create User Report (or the similar S20 – Create Server Report) flow. It is passed the search string (i.e. username string or servername string for S20).
It uses the OPA Connector – Find Users card to search for a user and return a list of user objects (including the id) and a count of the number use users found that match the string. This is using the “contains” clause with the List all Users for a Team API call. (If using the Find Servers action, it will search all servers for the string being found in any of the hostname, canonical_name or access_address.)
In this example it is expecting a single user (or server) to match and will error out if none, or more than one, are found.
In the second part of the workflow it will extract the ID from the single record found. Then this is used with an OPA Connector – Create Access Report card to get OPA to create the report. It returns the ID of the new report.
As mentioned earlier, reports are generated as an asynchronous process and the time taken to generate a report will depend on the amount of OPA objects it needs to process and other activities going on within you OPA team. Before downloading a report, you need to check for a completed status (“COMPLETED”, “COMPLETED_BUT_EMPTY”, or “ERROR”). A status of “CREATED” means OPA has accepted the request to create the report and “IN PROGRESS” means the report is being created but is not yet ready.
In this example set of flows, S50 – Is Report Ready is used to get the status and return it. It uses the OPA Connector – Retrieve Access Report card to get the details of the report (including the status) based on the Report ID passed into the sub-flow. It returns the status which is evaluated by the calling flow.
Once the report is ready to be downloaded, the S60 – Download Report card is used to download the report using the OPA Connector – Download Access Report card and this is returned as a text field to the calling flow.
From a Workflows design perspective, the last two highlighted flows are trivial and probably don’t justify separate helper flows, but it does make the high-level flows cleaner and easier to read.
There are other sub flows in use, but these ones show the use of the OPA Connector actions to search for users/servers, create the report, check the report status and download the report
Conclusion
Being able to run reports to see what access users have or how users can access resources is important for many Privileged Access Management implementations. Okta Privileged Access has an Access Report capability that has been accessable via APIs since the product went GA last December.
Okta has just released an Okta Privileged Access Workflows connector that includes action cards to create and download Access Reports. This article has explored how this connector can be used to do this and some considerations around how to structure Workflows using the connector actions.
Download the Code
Sample workflows used in this article can be found here.
One thought on “Generating Okta Privileged Access Reports with the new Workflows Connector”