Okta Entitlements for Disconnected Applications

OVERVIEW

With the release of Okta Identity Governance, one of the newly released features is entitlements at the application level. 

Entitlements open a deeper level of represented access for Access Reviews, Access Certification Campaigns and Access Requests through the representation of fine grain access and licensing that a given user has in a relationship to for the various applications they are assigned.

As of the writing of this article there are five key applications in the Okta Integration Network that support entitlements out of the box. A summery of the entitlement features of the applications is as follows:

SAAS APPLICATIONENTITLEMENTS
salesforce.com            Feature Licenses               
Permission Sets
Profiles
Public Groups
Roles
Google WorkspaceLicenses
Roles
Oracle NetSuiteRoles
boxRoles
Microsoft Office365Licenses
Roles
Okta Integration Network Applications with Entitlements support

The diagram below is great for providing additional context on how the Okta Identity Governance over all entitlement structure comes together. 

What are disconnected applications you may ask, well disconnected applications can typically be summarized in two categories:

  1. Legacy Applications – These are applications that do not have readily available APIs in which to pull the entitlement data or applications that are too costly or will be retired soon to create such an interface for
  2. SaaS Applications – Unfortunately not all SaaS (Software as a Service) applications provide API or other support for automated provisioning and / or entitlement management. This can also include license management related data as well.

Where customers are excited about the addition of entitlements for these applications, typically the question of what about representing “disconnected applications” comes up. Disconnected applications could be defined in the following ways:


With the use of Okta Workflows incorporating entitlements for applications that fall into the two categories above. This blog is in four parts around incorporating the following aspects around entitlement management. The four topics are:

  1. Dynamic creating of entitlements using table data in Okta Workflows
  2. Dynamic creating of entitlement bundles using table data in Okta Workflows
  3. Dynamic user assignments of entitlement bundles using table data in Okta Workflows
  4. Dynamic user assignments of individual entitlements using table data in Okta Workflows.

Before we get started with using the overall flow pack, lets take a look at a practical use case using what is covered in this and subsequent associated blogs on disconnected application entitlements.

This blog is the one that covers the first of these four topics, Dynamic creating of entitlements using table data in Okta Workflows. 

Once you have downloaded the flow pack identityGovernanceEntitlements.folder file, in the Okta Workflows console:

  1. Create a new folder titled [IDENTITY GOVERNANCE] Entitlements.
  2. Import the identityGovernanceEntitlements.folder file you downloaded by selecting the three dots, then choose Import. From there you can select the location of the identityGovernanceEntitlements.folder and then the file.

For the Dynamic creating of entitlements using table data Okta Workflow flow pack consists of one major (delegated flow) workflow and three helper flows.

The individual flows, what they perform in the flow pack and their relationship to the other flows is outlined below:

  1. [1.0] Process All Records – Dynamic Entitlement Creation – This is the main delegated Okta workflow that is used to process all of the active records in the Application Entitlements table. This flow identifies all the unique applications in the Application Entitlements table and calls the [1.1] Get Entitlement Types flow for each application found.
  2. [1.1] Get Entitlement Types – This flow is used to distill and pass on to be processed the individual unique Entitlement Types found in the Application Entitlements table for the given application passed by the [1.0] Process All Records – Dynamic Entitlement Creation flow. Each
  3. [1.2] Process Entitlement Type – This flow is used to process and thus create each of the entitlement structures for a given Entitlement Type.
  4. [1.3] Get Entitlement Structure – This flow is used to get the entitlements and create the entitlement structure JSON used to process and create each entitlement type in flow [1.2] Process Entitlement Type

The folder structure for the greater flow pack is as follows:

[IDENTITY GOVERNANCE] Entitlements - This is the parent folder for the over all bundle of flow packs around dynamic entitlement management.

At the root of this folder there are two flows and one table. These flows help establish environmental variables needed to call some of the APIs in the over all bundle. These flows are:

    • [HELPER] Initialize Global Variables: This helper flow is used to prompt for the values that will be stored to build out the Global Variables table.
    • [HELPER] Return Okta Tenant Base URL: This helper flow is used to take the values from the Global Variables table to formulate the base URL that is utilized when calling APIs against the Okta tenant APIs. (eg. https://<subdomain>.okta.com)

Below the parent folder are the individual flow pack folders. I have outlined what each flow pack in the bundle under the parent folder is used for.

  • Data Driven Entitlements Creation – This folder / flow pack is designed to dynamically create an entitlement structure for one or more applications using data provided in a table inside the flow pack. 

    This flow pack as well as the other ones that are in the overall bundle could easily be adapted to use other data sources such as Google Sheets, Excel online or taking advantage of Okta’s XaaS (Anything-as-a-source).
  • Data Driven Entitlement Bundle Creation – This folder / flow pack. is designed to dynamically create entitlement bundles utilizing entitlements either dynamically created by the Data Driven Entitlements Creation flow pack or manually created / edited in the Okta Admin Dashboard. 

    Like the Data Driven Entitlements Creation flow pack, the bundle data for one or more applications is stored in table data inside the flow pack.
  • Data Driven End User Bundle Assignments – This is a folder / flow pack. is designed to dynamically assign existing entitlement bundles to users inside of Okta for one or more applications that support entitlements and already have bundles created for them. Like the Data Driven Entitlements Creation flow pack, the bundle data for one or more applications / users is stored in table data inside the flow pack.
  • Data Driven End User Entitlement Assignments – This a folder / flow pack. is designed to dynamically assign existing entitlements to users inside of Okta for one or more applications that support entitlements and already have entitlements created for them. Like the Data Driven Entitlements Creation flow pack, the bundle data for one or more applications / users is stored in table data inside the flow pack.

PREREQUISITS

Before you start the flow pack to create the entitlements for given applications that are specified in the Application Entitlements table you will need to:

API Key:

You will need to create an API connector that uses an API key created in your Okta tenant. To do so you will need to create an API Key. Be sure to capture the API Key somewhere secure as you will need it for the connector.

To create the API Connector, add an API connector and choose Custom as the type. Then for the Header type in Authorization. For the value type in SSWS <API Key>. The <API Key> is that value you coped from the step above.

Okta Connector

Open each flow in the flow pack and where there is an Okta connector, select the Okta connector in your environment. If you have not create an Okta connector in your environment, you will need to create one.

In each flow that has an API Connector card you will need to select the API connector that you created in the step above.

Okta Applications

You will need to populate the Application Entitlements table with the desired applications, entitlement types and individual entitlements. This flow pack is capable of processing entitlements for multiple applications inside your Okta tenant.

As a reminder the applications will need to already exist in your Okta tenant as well as for each application have the Identity Governance – Governance Engine enabled.

Currently the following applications types support the Governance Engine:

SWA (OIN): Secure Web Authentication applications in the Okta Integration Network. Custom SWA applications are not supported at this time.

SAML: Applications that support SAML authentication

WS-Federation: Applications that support WS-Federation authentication

OpenID Connect: Applications that support OpenID Connect

Initialization Variables

You will need to run the [HELPER] Initialize Global Variables flow to establish the global variables used by various flow packs inside the overall flow pack here. 

As of the writing of this blog, there are not prebuilt cards for many of the entitlement management APIs. Additionally the Okta Connector – Custom API card is not authorized to call many of the entitlement management APIs. Thus there is currently a need to use the Raw Request API card. To facilitate the utilization of this card an understanding of the Okta tenant base URL is needed. The [HELPER] Initialize Global Variables flow will populate that table based on inputs for the flow storing them in a Global Variables table.

This flow can be found at the root of the overall flow pack in the [IDENTITY GOVERNANCE] Entitlements folder.

The inputs are OktaSubdomain and OktaEnvironment. These two parts can be found in your Okta tenant URL when you login to Okta enduser dashboard with the Okta subdomain first and the Okta environment second. (ex. https://<oktasubdomain>.okta.com or https://<oktasubdomain>.oktapreview.com.) Simply you open the flow, simply click the Run button, provide the two input values and click Run button on the input dialog. 

USING THE FLOW PACK

For the example in this blog, I am using the Adobe Okta Integration Network application as my sample application. Once you have all of the Prerequisites completed lets populate our table for this flow pack with some data shall we? 

The table in question is the Application Entitlements table contained under Tables in the Data Driven Entitlements Creation flow pack folder.

To upload the sample data, open the Application Entitlements, then choose Import where you can then select the file (applicationsEntitlements.csv) that you just downloaded to import.

This flow pack is capable of processing entitlements for multiple application entitlement assignments inside your Okta tenant.

The columns of this table are as follows:

COLUMN NAMECOLUMN DESCRIPTIONEXAMPLE
Application NameThe name of the application that you wish to apply the
entitlements. This needs to be an existing application in your Okta tenant.
Adobe
EntitlementTypeName             The name of the actual entitlement that you
wish to apply the entitlements. Typically this will have multiple values associated
with it but
not always.

Licenses
EntitlementNameThis is the name of one of the values under the
entitlement
that represents the possible one to one or one to
many relationship to a given user
Dreamweaver
EntitlementType DescriptionThe description show for the entitlement type in the Entitlement Type Name in the table.The Adobe Licenses available
EntitlementNameDescriptionThis is the displayed description for the actual
entitlement granted.
This can be very useful in access certification
campaigns
Dreamweaver license for the Adobe suite
EntitlementExternalValueThis represents the back end / external value
for the entitlement entity as represented in
the application itself.
User-Dreamweaver
EntitlementTypeValueThis represents the back en / external value for the entitlement itself as represented on the back end applicationLicenses
ProcessedThis flag indicates whether the given record
has already been processed. Once processed the value will automatically be set to true. To reprocess the record you will need to change the value to false.
false
Application Entitlements Table

Once the Applications Entitlements table has been populated and all of the Workflows mentioned above have been enabled…

You will simply open the open the [1.0] Process All Records – Dynamic Entitlement Creation workflow and click on the Run button.

You will then be presented with the following prompts. The only one that you need to set if desired is the one to “Clear Error Report Table”. If you want to clear previous entries from the Error Report table set that value to True.

Then click Run Test.

Once completed you will see a green checkmark on the card in the flow. For Each – Ignore Errors card as shown below. 

Now you will be able to go to the various applications in your Okta tenant that you specified in the Application Entitlement table an you will see the entitlements dynamically created from the data in the table.  

If you do not see the desired results, open the Error Report Table to find out what flows had errors and the nature of the error(s).

You can also execute the [1.0] Process All Records – Dynamic Entitlement Creation flow you can also uses the Delegated Flows option on the Okta Admin Dashboard as shown below.

Congratulations!! You have now completed the creation of entitlements for given application(s) with the entitlements you specified.

In the next post you will see how to dynamically create entitlement bundles from the entitlements that you just created.

Note: The original flow pack was authored by Marc Miller. Updates have been made by Jennifer Saylor and Ajay Seetharam.

5 thoughts on “Okta Entitlements for Disconnected Applications

  1. I found that you need to be cautious when following these instructions. I created a brand new application called ‘Adobe’ to follow the guide. However, I had an inactive applications that also began with ‘Adobe’ (i.e., ‘Adobe Experience Manager’). The Okta Workflow kept picking up the deactivated application and used this deactivated app when running the API calls. The API was failing due to this. Once I completely deleted the inactive application, everything ran as documented without issue.

    1. Jason, let me take another look at this as I purposely put logic in the flow pack to filter out deactivated instances of the app with the same name. What particular flow and flow pack did you run into this as it would help me take a look to resolve the issue?

  2. Jason, I will have to take a look at the flow pack as I purposely put logic in their to make sure the instance of the app that I grab as well as entitlements is active when their might be two apps / entitlements / entitlement bundles with the same name. What specific flow and flow pack did you run into this as it would help me address the issue quickly?

Leave a Reply