Okta Entitlements for Disconnected Applications – Dynamic Entitlement Bundle Assignments

OVERVIEW

This blog is a continuation of the Okta Entitlements for Disconnected Applications – Dynamic Entitlement Bundle Creation that I posted previously. Some of the introductory content is duplicate to reenforce some of the basic concepts around Okta Identity Governance – Entitlement Management.

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.

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

SAAS APPLICATION	ENTITLEMENTS
salesforce.com	Feature Licenses                Permission Sets Profiles Public Groups Roles
Google Workspace	Licenses Roles
Oracle NetSuite	Roles
box	Roles
Microsoft Office365	Licenses Roles

This blog is the one that covers Dynamic assignment of entitlement bundles using table data in Okta Workflows for applications that do not currently in the list above or are disconnected applications.

In the previous blogs in this series we took a look at the dynamic creation of entitlements using table data and Okta Workflows in the Okta Entitlements for Disconnected Apps post as well the dynamic creation of entitlement bundles for those entitlements.

In this post, we are now going to look at assigning entitlement bundles using table data and Okta Workflows utilizing existing entitlement bundles for give applications. Note this flow pack will work even if you manually created the entitlements and / or entitlement bundles using other means such as the Okta administrator dashboard.

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.

To summarize the relationship structure again for review, each application can have a serious of entitlements and those entitlements can have one or more values. When I refer to “entitlement types” think of that as the high level entitlement such as Licenses or Roles. Then when I refer to “entitlement values” this refers to the actual possible values of the entitlement such as Adobe Creative Cloud or Global Administrator.

In the previous blogs in this series we took a look at the dynamic creation of entitlements using table data and Okta Workflows in the Okta Entitlements for Disconnected Apps post. Then we looked at dynamically creating entitlement bundles using table data and Okta Workflows.

The updated flow pack can be downloaded below (as of January 2025). This version incorporates the latest API updates, so previous flow packs will no longer function correctly. We are continually making enhancements:

If you have not already done so, 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.

In this post, we are now going to look at assigning those entitlement bundles using table data and Okta Workflows. Note this flow pack will work even if you manually created the entitlements and / or entitlement bundles using other means such as the Okta administrator dashboard.

There are 8 flows in this flow pack. The reason for so many flows is that this flow pack does not simply assign new entitlement bundles to the users defined in the table data but rather treats the table data as the authoritative source for entitlement bundle assignments for end users in the table data for the applications represented in the table data.

In other words if a user defined in the table for given applications, has entitlement bundles assigned to them that are not defined in the table data then they are removed.

After the unrepresented entitlement bundles are removed then any entitlement bundles that the user does not have currently assigned but are represented in the table data for given applications for that user, they are the assigned / added.

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 Assignment of Entitlement Bundles – This is the main delegated Okta workflow that is used to process all of the active records in the Entitlement Bundles table. This flow sends each user assignment record to the [1.1] Process a users entitlements for a each applications.
   
2. [1.1] Process a users entitlements for a each applications – This flow is used process each application that is assigned to that user passed from the [1.0] Process All Records – Dynamic Assignment of Entitlement Bundles flow. Since an entitlement bundle can only be assigned to one application and is application specific it is necessary to treat each applications entitlement bundle assignments to the user individually. This flow then calls the [1.2] Get User Entitlement Bundle Deltas flow. Each
   
3. [1.2] Get User Entitlement Bundle Deltas – This flow is used to identify both the current entitlement bundle assigned to the give user for the given application as well as identify the entitlement bundles that should be assigned to the give user for the given application. As mentioned above this flow pack will consider the table data to be the source of truth and resolve any bundle assignment conflicts that result.
   
   The flow having identified the delta of what entitlement bundles should be added as well as any entitlement bundles should be removed, will first remove the entitlement bundles that should be removed followed by adding the new entitlement bundles assigned to the given user for the given application using that table data as the source of truth.
   
   To compile the needed data to understand what to add and what to remove the flow calls both the [1.3.0] Get Specified Users Current Entitlements and the [1.3.1] Get Specific user entitlements for a given applications flows.
   
   To then add and / or remove entitlement bundles to reconcile the table data as the source of truth, the [1.3.2] Grant / Revoke Entitlement Bundle (Entitlement Bundle Id) is utilized
   
4. [1.3.0] Get Specified Users Current Entitlements – This flow is used to get the current entitlement bundles to the give user for the given application and return it to [1.2] Get User Entitlement Bundle Deltas flow.
   
5. [1.3.1] Get Specific user entitlements for a given applications – This flow to compile the entitlement bundles that should be assigned to the give user for the given application and return it to [1.2] Get User Entitlement Bundle Deltas flow. This flow utilizes [1.4] Get User Data Entitlement Ids to create the structure to be added for the give user for the given application.
   
6. [1.3.2] Grant / Revoke Entitlement Bundle (Entitlement Bundle Id) – is used to make the API call needed to either add or remove entitlement bundles for the give user for the given application as utilized in the[1.2] Get User Entitlement Bundle Deltas to do so.
   
7. [1.4] Get User Data Entitlement Ids – This flow is used create the entitlement bundle structure and create the entitlement bundle structure JSON used to assign new entitlement bundles for the give user for the given application. To get the actual individual entitlement bundle ID the [1.5] Get Entitlement Bundles ID flow is utilized.
   
8. [1.5] Get Entitlement Bundles ID – This flow is used to get the actual bundle ID for the specified entitlement bundle for a specified application. This flow is utilized by the [1.4] Get User Data Entitlement Ids flow.

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:

If you have not already done so from the first blog in this series I put together “Okta Entitlements for Disconnected Apps’, you will need to do the following:

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.

NOTE: This blog is making the assumption that you have already either followed the Data Driven Entitlements Creation flow pack instructions in my Okta Entitlements for Disconnected Apps blog or created the desired entitlements using the Okta Admin Dashboard. 

Additionally, this blog is making the assumption that you already either followed the Data Driven Entitlement Bundle Creation flow pack instructions in my Okta Entitlements for Disconnected Applications – Dynamic Entitlement Bundle Creation blog or created the desired entitlement bundles using the Okta Admin Dashboard. 

In short the entitlements and corresponding entitlement bundles to be included in the entitlement bundles you will define here need to already exist for the application(s) you specify for this flow pack.

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? 

You will need to populate the Entitlement Bundle Assignments table with the desired users you wish to assign the entitlement bundle(s) to, the application(s) associated with those entitlement bundle(s), entitlement bundles and associated entitlements for those bundles.  You can find the table under the Data Driven End User Bundle Assignments folder.

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

I have provided some sample data for this application which can be uploaded using the file below:

To upload the sample data, open the Entitlement Bundle Assignments, then choose Import where you can then select the file (entitlementBundleAssignments.csv) that you just downloaded to import.

The columns of Entitlement Bundle Assignments table are as follows:

COLUMN NAME	COLUMN DESCRIPTION	EXAMPLE
Application  Name	The name of the application that you wish to apply assign the entitlements bundles for. This needs to be an existing application in your Okta tenant.	Adobe
Okta Username	The name of the actual user referenced by their Okta username (login) inside your Okta tenant. The users need to exist in Okta before this flow pack is run. 	john.doe@oktaprise.com
Entitlement Bundle Name	This is the name the actual entitlement bundle to be assigned to the Okta user in a given row for the application specified in that row. The Okta entitlement bundle needs to exist in the Okta tenant before running this flow pack. 	Adobe Pro Bundle

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 Assignment of Entitlement Bundles 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 Entitlement Bundles table an you will see the entitlement bundles dynamically assigned to the users specified in the data in the table.  When you view the users dynamically assigned you will be able to see the individual entitlements assigned to those users.

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

There is the ability to process / assign a single entitlement bundle to a single Okta user for a specific application by running the [1.0] Grant / Revoke. Single Entitlement Bundle delegated flow. There are various inputs that will need to be provided when running the this delegated flow. Those inputs are as follows:

COLUMN NAME	COLUMN DESCRIPTION	EXAMPLE
Application  Name	The name of the application that you wish to apply assign the entitlements bundles for. This needs to be an existing application in your Okta tenant.	Adobe
Okta Username	The name of the actual user referenced by their Okta username (login) inside your Okta tenant. The users need to exist in Okta before this flow pack is run. 	john.doe@oktaprise.com
Entitlement Bundle Name	This is the name the actual entitlement bundle to be assigned to the Okta user in a given row for the application specified in that row.  The Okta entitlement bundle needs to exist in the Okta tenant before running this flow pack. 	Adobe Pro Bundle
Action	The action that should be performed. Allow means that the entitlement bundle if not already assigned to the user will be assigned.  Deny will if the bundle is assigned will be removed.	Allow

Congratulations!! You have now completed the dynamic assignment of entitlement bundles for given application(s) with the entitlement bundles you assigned to the users for the specified application using the table data as the authoritative source.

Below is a video of what we have done so far in action:

In the next post you will see how to dynamically assign individual entitlements to users for specified applications using table data.

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