This blog post is part two in the series. The first post can be found here: Auth0 Integration with Okta Workflows – Part One
For large organizations comprised of numerous independently managed business units, centralizing identity can be extremely challenging. Okta hub-spoke architecture model has been key in solving this issue for many organizations for a number of years now.
The hub and spoke model enables organizations to physically and logically separate a collection of identities from one another through the use of multiple Okta tenants (also referred to as Okta Orgs). The flexibility that this model allows organizations to address complex use cases typically driven by business, technical, and/or compliance requirements. Through the use of the Okta Integration Network’s (OIN) Org2Org connector, multiple Okta orgs can be integrated together to enable both single sign-on (SSO) and provisioning within a matter of minutes.
Now that the use of Okta’s Customer Identity Cloud (aka Auth0) is increasing, it will be more likely that an Auth0 org will be part of the mix when configuring a hub and spoke model. Previously, Okta’s Org2Org connector provided user provisioning, but when it comes to Auth0, Okta Workflows can perform a similar role.
This blog post provides an example of how Okta Workflows can be used for user provisioning from Auth0 to Okta.
Use Case
There could be a few reasons why an Auth0 org might need to be included in a hub and spoke model. As an example, in a B2B scenario, you might want to allow a business partner to access your applications and that business partner may be using Auth0. This relationship is represented by the following diagram:
In the above diagram, APAC Business Partners authenticate against an Auth0 org, which provides the users with access to applications provisioned from the Company Hub. An external Identity Provider configured in the hub provides an option for Just In Time (JIT) provisioning. But you may want to provision users off-line, so their respective accounts can be push into the assigned applications before they sign in for the first time.
In Okta, application access is usually controlled via group membership. In Auth0, application access is usually controlled via role (Role Based Access Control). So in order to provision users from Auth0 to Okta, we need to read the list or users assigned to a particular role. Additional information about each user may also be required, so we then need to read the users metadata. This interaction is represented by the following diagram:
In the above diagram, processing is as follows:
- Read the list of users assigned to a particular role. In this example we are using the Salesforce role.
- Read each users metadata and retrieve the users first and last name.
- Create the user in Okta and assign the user to the user to the Salesforce group. This will then provision the user into Salesforce.
In order to configure the workflow example, follow the steps below:
Step 1 – Configure Auth0
In this step, we are going to configure the Auth0 tenant to allow Okta Workflows to interact with it via the Auth0 API.
Create M2M Application
In the Auth0 administration console, go to Applications and create a new Machine to Machine app. If you followed the configuration process for part one in this blog series, you can re-use the previously created application. Save the Domain, Client ID and Client Secret from the application as these will be required in a subsequent step.
On the API’s tab, Authorize access to the Auth0 Management API if it has not already been authorized. Once the Auth0 Management API is authorized, click on the down arrow as shown below:
This will bring up the available permissions on the API. Ensure permissions read:users and read:roles have been enabled.
Create Role
We now need to create a role that provides access to the application provisioned in the Okta hub. In the Auth0 administration console, go to User Management > Roles and create a new role and give it a meaningful name. An Auth0 role would normally require configured permissions, but in this case, we are just using the role similar to a group in Okta, so no permissions are required.
Ensure that a few test users are assigned to the role.
Take note of the Role ID as this will be required in a subsequent step.
Here is an example of my Role:
Step 2 – Configure Okta
Create Group
In this step we need to create a group in Okta that the users can be provisioned into. In the Okta administration console go to Directory > groups and create a new group.
Take note of the Group ID as this will be required in a subsequent step.
Note: The Group ID can be found in the URL when the group is opened via the administration console.
If you would like to test the users access end-to-end, then allocate the group to an application that includes user provisioning like Salesforce for example.
Create External IDP and Routing Rules
This is an optional step. If you would like to test the users access end-to-end then your Auth0 tenant will need to be added to your Okta tenant as an external Identity Provider. Additionally, if the users will access your Okta tenant directly, then you will also need to configure routing rules that will send the user to the AuthO IDP.
The instructions for this step can be found here: Setup Auth0 as an External IDP
Step 3 – Configure Sample Workflow
You can download the workflow sample from here: Auth0 User Provisioning.
The workflow is structured as per the following diagram:
The sequence is as follows:
- The main flow, [main] Provision New Users, is started via a set schedule.
- Helper flow, [util] Load Configuration, is called to load static values stored in a workflow table
- Helper flow, [util] Get Access Token, is called to generate an OAuth Access Token via your Auth0 tenant. This flow uses an API Connector to call the token endpoint via the Auth0 Management API.
- Helper flow, [util] Get Users Assigned to Role, is called to retrieve the list of users assigned to the respective role in your Auth0 tenant. This flow uses an API Connector to call the role endpoint via the Auth0 Management API.
- Helper flow, [util] Process User, is called for every user retrieved from the previous step. This flow uses the Okta connector to create the respective user and assigned them to the desired group.
The workflow sample also includes two tables:
- configuration – Used to store static configuration values
- user – Dynamic state tables used during runtime
Step 3.1 – Import Sample and Load Configuration
Create a folder within the workflow console and import the supplied sample.
Once that has completed, open the configuration table and import the supplied sample data (configuration.csv). This will result in the following records:
Next you will need to update each record to the correct value for your environment. These will be the values saved during the previous steps.
Step 3.2 – Update Flows
If you do not already have an Okta connector in your workflow environment, then create one now. This connector points to the underlying Okta tenant.
Next, open the flow titles [util] Process User and update the Okta Custom API Action card to use your Okta connector.
Next, open the flow titled [main] Provision New Users. Update the set schedule on the Schedule Flow card as required. By default, it is set to run daily.
Finally, turn each flow on.
Testing the Workflow
To test the flow, do the following:
(a) Within your Auth0 tenant, ensure you have at least one user assigned to the role created in Step 1. Ensure that user has firstName and lastName as part of their metadata. EG.
{
"firstName": "Chuck",
"lastName": "Norris"
}(b) Ensure that same user does not already exist in your Okta tenant.
(c) Within the workflow console, open the flow titled [main] Provision New Users and click the Test button.
(d) If the flows complete successfully, the respective user should have been created in Okta and be assigned to the group created in Step 2.
(e) Finally, log into Okta as that user. If your routing rules have been setup correctly, you should be directed to your Auth0 tenant to authenticate. Once authentication is successful, you should be landed on the Okta portal with access to the apps attached to the group. You should be able to click on the chicklet and be signed into the respective application.
