R

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.

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.

Using recursive SQL common table expressions (CTE) to build corporate hierachy reports is well documented use case for SQL CTE’s. I leveraged a SQL CTE to build a Shiny data table report that returns a client’s top down hierarchy based on user selection of an employee ID. The Shiny app uses the squr and RODBC pacakges to call the SQL script.
That report was useful but you never really know what someone wants until they ask.

Google Data Studio is a basic, yet functional report building and dashboard service for when you don’t need or want the power of something like RStudio Shiny, Power BI or Tableau. It has many data connectors and is tightly integrated into Google’s authentication ecosystem. I recently used it to build a simple yet effective business intelligence dashboard report for a client that saved them significant annual spend on a content analytics service.