Posts

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.

I built a Shiny application recently for a client that accepts uploaded files and matches data attributes in those files to corporate directory information stored on the server in an RDS file. After some trial and error I was able to piece together something useful and produce a self-service Shiny solution. This example illustrates the key concept of properly referencing reactive data objects when accessing them outside the function that created them in the following “contents()” and “mergedData()” references.

Okta is a popular single sign-on (SSO) service provider that enables secure application connections. It has a well documented API I reference when creating client reports based on data in their Okta instances.
REST API endpoint services typically limit the number of records returned per call via pagination. Okta API pagination is cursor based and pagination links are included in the link headers of responses. This basic example uses the httr and jsonlite packages to illustrate getting all records via a particular Okta API GET request by retrieving, parsing and following the link header values.

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.

A client asked me to develop a method to post a recurring message to a particular Slack channel. The slackr package easily enables inbound webhook Slack channel message posting in just a few lines of R.

library(slackr)

setwd("C:/slackproject/")
slackr_setup(config_file="slackr.dcf")

text_slackr('Any text message you wish to push to the Slack channel goes here.', 
as_user=FALSE)

This is the configuration information file referenced in that script:

api_token: <your slack API token>
channel: <name-of-slack-channel>
icon_emoji: :<emoji name>:
username: <you can insert any name here - doesn't have to be a 'real' slack account>