A common request asked is how to look at past access request events. Currently you can see the results of the requests in the Okta System Log and also in the Okta Identity Governance (OIG) Access Requests admin console. This article will explore these.
Article contents:
This is still an early release product, so expect to see more logging and reporting in this area as the product develops.
Overview
Okta Identity Governance (OIG) Access Requests is an external system performing changes to data objects in Okta Identity Cloud (Okta) via APIs. This is the same as if ServiceNow or a custom program were making changes to Okta via APIs.
Thus from a logging perspective, you will see the activity in the OIG Access Request component itself and in the Okta System log. These are discussed in the following sections.
Events in the Okta System Log
Change to users, group memberships and application assignments from OIG Access Requests are stored as events in the Okta System Log like any other events. They can be explored using the System Log menu item in the Okta Admin console or you could develop custom reports in Okta Workflows.
You could also plumb the events out to a SIEM or reporting tool, as the Okta system log only stores events for a limited time. But we don’t cover that here.
Native Events and Reporting
All events from the OIG Access Requests component currently show as coming from one of two actors:
- Okta AtSpoke Connector (PublicClientAppEntity) – for all user, group, application events, and
- Okta AtSpoke Connector (PublicClientApp) – for OIDC access token messages
Note, this actor name will likely change at General Availability. You can filter on this actor name to see all events from Access Requests.
These events show the changes to the Okta objects, but not all of the detail of the request/approval flows in Access Requests.
Reporting with Workflows
I love Okta Workflows – it is our Swiss Army knife for any form of automation. It is reasonably straightforward to build some flows to extract OIG Access Request events from the system log. The [Okta] Search System Logs card with an Actor Display Name of “Okta AtSpoke Connector” (see note about about pre-GA name above) will return all Access Request events from the syslog. Note that you need to Grant the okta.logs.read scope in the Okta Workflows OAuth application for this card to work.
We won’t go into the structure or processing of the event log objects here. But the Target(s) object list may contain an AppUser (application user), an AppInstance (application), a User, or a UserGroup (group). These objects often contain the identifier (like username) and display name.
I built a set of flows to accomplish this:
- A master flow that reads the syslog events using the card above, and streaming them to a subflow
- A sub (helper) flow to extract the event type and description, target list and published date/time. It then uses another helper flow to find the four targets (AppUser, AppInstance, User or UserGroup) and extract the name and ID. These are written to the table.
- A sub (helper) flow to find the specific target in the list and extract the name and ID.
The resulting table of processes events looks like the following.
This is just an example, but Workflows does give a lot of flexibility in processing the outcome. You could export the table to a CSV file, store it on a Google drive and notify relevant people via email.
Viewing Requests in the Access Requests UI
To see the detail of the access request flow, including approvals, fields, and interactions, you need to use the OIG Access Requests UI as an administrator. An administrator can see all requests and use the filter function to home in on specific requests.
Viewing All Requests
To see all requests (historical and current) you can select the All option under the Requests menu item. You can also see the flows assigned to different teams.
Selecting one of the requests shows the full history of that request.
Note that it’s also including the chat history of the request – so this is providing a complete history of what occurred.
Filtering Requests
There is a Filters function for the Requests view. It allows you to select multiple fields, and for each field you can select multiple values.
The selection above is showing all requests where the Requester = Seymour Skinner. This results in a filtered list of requests.
Similarly I could select a specific workflow to filter on.
Resulting in a list of all requests for that workflow.
Depending on how you structure your flows, this may be showing requests for specific groups (roles) or applications.
As mentioned earlier, you can stack up filters. For example, I could see all requests from a specific user for a specific resource.
Hook into an ITSM Tool in a Flow
OIG Access Requests provides integration with ITSM tools, such as ServiceNow and Jira. You can include an action in a flow to write all of the request details into a ticket.
The following figure shows a ServiceNow ticket logged in a flow.
Note that this is implemented at the flow level – you need to include it in every flow you want to log a ticket from. However this could feed into any reporting already used in the ITSM tool.
More details on the ServiceNow integration can be found in Integrating ServiceNow with OIG Access Requests.
Conclusion
Being able to see what went on in a security product like OIG Access Requests is a necessary feature. This article has explored the different places access request history is stored and how to access it.
Sample Code
The workflows example described above can be downloaded from https://github.com/iamse-blog/workflows-templates/tree/main/dae-oig02-AccessRequestsSyslogReporting
