Okta continuously improves administration features. Recent additions include new email notification options for administrative functions. These additions are helpful but customers often have more refined needs that require some development effort. Fortunately, the Okta system log API provides access to nearly any event you might want to monitor or use to extend reporting processes that add value in your organization and enhance information transparency. While the Okta API provides integration capabilities for several security information and event management (SIEM) products, those solutions are generally focused on threat analysis and general monitoring.

Much of my work lately involves interacting with the Okta API. It is a well documented API for those familiar with RESTful API development in their language of choice. If that doesn’t describe you (yet) then hopefully this post will help those of you with some R programming knowledge. Scenario: You want to find out which credential a particular Okta user profile is using when accessing a specfic Okta application and change a credential value (in this example ‘userName’) if the current value doesn’t match the desired value.

I finally had some time to revist and improve a past project. This example illustrates retrieving all Okta user profiles assigned to a given application in Okta. As outlined in my earlier post, Okta limits the number of records returned depending on the API request so follow their cursor based pagination URLs to return all records if the number exceeds the API limit. There are many reasons why you might want to retrieve this data.

Some projects evolve naturally by combining previous efforts into something new and useful. This happened recently when I fullfiled a client request by extending an existing RStudio Shiny application using what initially seemed like unrelated, separate components. End users could upload a software vendor inventory text file in the existing Shiny application. Key attributes in that file were joined across several database views and a Shiny data table report returned the aggregated data to the user.

A client wanted an easy way to quickly view upcoming event lists for any of their G Suite domain’s Google Resource Calendars. I tried keeping the solution entirely within R by using the googleAuthR package but domain-wide delegated authentication didn’t work properly for me so I reverted to Python. Without too much anguish I wrote a working parameterized script that returns Google resource calendar event details based on resource calendar ID and event count script arguments.