Configure workspace-level SCIM provisioning using Okta (legacy)

Important

This documentation has been retired and might not be updated. Workspace-level SCIM provisioning is legacy. Databricks recommends that you use account-level SCIM provisioning, see Sync users and groups from your identity provider.

Preview

This feature is in Public Preview.

This section describes how to set up provisioning from Okta directly to Databricks workspaces.

Get the API token and SCIM URL in Databricks

As a Databricks workspace administrator, generate a personal access token. See Token management. Store the personal access token in a secure location.

Important

The user who owns this personal access token must not be managed within Okta. Otherwise, removing the user from Okta would disrupt the SCIM integration.
Make a note of the following URL, which is required for configuring Okta:

https://<databricks-instance>/api/2.0/preview/scim/v2

Replace <databricks-instance> with the workspace URL of your Databricks deployment. See Get identifiers for workspace objects.

Keep this browser tab open.

Configure SCIM provisioning in the Databricks SAML application in Okta

Go to Applications and click Databricks.
Click Provisioning. Enter the following information obtained from the above section:
- Provisioning Base URL: the provisioning endpoint
- Provisioning API Token: the personal access token
Click Test API Credentials.
Reload the Provisioning tab. Additional settings appear after a successful test of the API credentials.
To configure the behavior when pushing Okta changes to Databricks, click To App.
- In General, click Edit. Enable the features you need. Databricks recommends enabling Create users at a minimum.
- In Databricks Attribute Mappings, verify your Databricks Attribute Mappings. These mappings will depend on the options you enabled above. You can add and edit mappings to fit your needs. See Map application attributes on the Provisioning page in the Okta documentation.
To configure the behavior when pushing Databricks changes to Okta, click To Okta. The default settings work well for Databricks provisioning. If you want to update the default settings and attribute mappings, see Provisioning and Deprovisioning in the Okta documentation.

Test the integration

To test the configuration, use Okta to invite a user to your Databricks workspace.

In Okta, go to Applications and click Databricks.
Click the Assign tab, then Assign to people.
Search for an Okta user, and click Assign.
Confirm the user’s details. Click Done.
In the Databricks workspace admin settings page, click Identity and access tab, then go to the Users section and confirm that the user is added. At a minimum, grant the user the Workspace entitlement.

After this simple test, you can perform bulk operations, as described in the following sections.

Delete a deactivated user from the workspace

If you delete a user from the workspace-level Databricks application in Okta, the user is deactivated in the Databricks workspace but is not removed from the workspace. A deactivated user does not have the workspace-access or databricks-sql-access entitlement. Reactivating a deactivated user is reversible, either by re-adding the user in Okta or by using the Databricks SCIM API directly. Removing a user from a Databricks workspace is disruptive and non-reversible.

Important

Do not deactivate the administrator who configured the Okta SCIM provisioning app. Otherwise, the SCIM integration cannot authenticate to Databricks.

To remove a user from a Databricks workspace:

In the admin settings page, go to the Users tab.
Click the x at the end of the line for the user.

Be aware of the following consequences of removing the user:

Applications or scripts that use the tokens generated by the user will no longer be able to access the Databricks API
Jobs owned by the user will fail
Clusters owned by the user will stop
Queries or dashboards created by the user and shared using the Run as Owner credential will have to be assigned to a new owner to prevent sharing from failing