Overview
This blog post will walk you through how to programmatically create and delete Tuples within Okta’s Fine Grained Authorization (FGA) product triggered by an Access Request in Okta Identity Governance (OIG). FGA is an early-stage product Okta is building to solve fine grained authorization at scale. FGA is a Relationship Based Access Control model that enables you to express rules based on the relationships users have with objects and objects have with other objects. This type of model reduces the difficulty of managing complex authorization models. Tuples in FGA manage the relationship between users and objects defined in your FGA model.
Although FGA is primarily used with Okta’s Customer Identity Cloud for managing complex authorization models, companies may also want to extend the product to managing privileges of internal users. This blog post will focus primarily on this use cases, where internal employees are requesting higher levels of privilege. By leveraging the extensibility of Okta Identity Governance (OIG) integrated with Okta Workflows we can manage these Tuples programmatically giving admins the power to approve or deny elevated permission requests where those permissions are defined and managed in FGA.
Prerequisites
- An Okta Org with Workflows and OIG provisioned
- OIG integrated with Okta Workflows – View this blog post for more information
- An FGA Free trial account – Create one here
- Active API keys in your FGA model – Instructions can be found here
Workflows Configuration
There are four main components of this project in Workflows. The first two components are tables for converting values that we collect in OIG to IDs that the FGA API can ingest. The other two components are two Workflows: one for creating Tuples and one for deleting them.
One of the challenges that must be overcome when integrating OIG with FGA is when defining relationships with Tuples in FGA, user and object IDs must be used. The tables shown below can be leveraged to convert Okta Usernames and objects (in this case folders) to IDs that the FGA API can recognize.
As far as the required Workflows go there are just two, one to create the Tuple and one to delete it. These Workflows are identical other than the write/delete parameter in the body of the API call in the Compose card.
The Workflows can be broken down into a few key parts. The first part is the event that triggers the Workflow. We are using a delegated flow since this will be triggered from OIG. We are passing the parameters requesterEmail – the user requesting elevated privileges, folderRequested – the folder that the user is requesting an elevated privilege to, and levelOfAccess – the elevated permission that the user is requesting.
In the next key part of the Workflow, the search and read table cards will come in handy to convert the parameters passed from OIG (Folder and Usernames) to IDs that can be used to create Tuples in our FGA model. Those IDs are then used in the compose card to create the body of the API call to the FGA Tuple write endpoint.
At the moment only the client credential flow is supported for making the FGA API call to a hosted model. Therefore in the last key part of the Workflow, first there is a call to the GET Token endpoint to get a valid access token, then there is an API call to the Write Tuple endpoint with the header and body containing the necessary information that we’ve already collected.
Configuring the Access Request
When creating the Access Request, the answers to the questions asked will be passed over to Workflows as the requesterEmail, folderRequested, and levelOfAccess parameter. Using defined drop down lists will make doing the table lookups much easier when the parameters are passed to the Workflow.
Once the questions are answered and the approval is done by using the Run a Workflow action, the create Tuple delegated flow can be called and the required parameters can be passed over.
The screenshot above depicts an Access Request with a timer. Timers can be added for time based use cases where the Delete Tuple delegated flow can be called once the timer has expired. Once logic is added to each Task and Action, the Access Request can be published. Upon a successful approval OIG will pass the defined parameters over to the Create Tuple Workflow which will convert that information to valid IDs and programmatically create new relationships in the FGA model. After the timer has expired, the same event will kick off, removing that relationship from the model and taking away that temporary elevated access.
IAMSE