SCIM Provisioning Conflict with Pre-existing DataHub Users (Okta) – DataHub Customer Support Portal

Area: Deployment Issues

Sub-Area: SCIM / Identity Provisioning

Issue

When enabling SCIM provisioning in DataHub with Okta after users have already been manually created in DataHub, Okta fails to provision those pre-existing users and displays an error on each affected user's Okta profile. This occurs because manually created DataHub users carry a NATIVE origin type. When Okta's SCIM client attempts to create these users via the SCIM API, DataHub detects that a user with the same username or email already exists and returns a 409 Conflict response. New users who have never existed in DataHub before SCIM was enabled are unaffected and provision successfully.

Error Messages

Resource with name <username> already exists.
409 Conflict — SCIM user creation failed for pre-existing DataHub user

You Might Be Asking

Why does SCIM work for new users but fail for users who were already in DataHub?
Can DataHub automatically link (soft-match) existing users to their SCIM identities?
Will fixing this issue affect data ownership or notification settings for existing users?
Do I have to delete all my existing users to enable SCIM?

Root Cause

DataHub's SCIM endpoint checks whether a user already exists before attempting to create them. If a match is found, the endpoint throws a ConflictResourceException rather than updating the existing record. The relevant logic (in AbstractScimRepository.java) is shown below:

if (_entityService.exists(systemOperationContext, urn, false)) {
  throw new ConflictResourceException(
      "Resource with name " + nameFromResource(scimResource) + " already exists.");
}

Users created manually through the DataHub UI or API are stored with an origin aspect of type NATIVE. Because no SCIM externalId is present on these records, the SCIM endpoint cannot distinguish them from a truly new user and instead raises a conflict error.

This deficiency was addressed in DataHub Cloud v0.3.14.1 (commit f2fab3867f, merged September 2025). The fix allows the SCIM endpoint to recognize NATIVE-origin users and update them in place rather than attempting to create a duplicate.

Solution

Choose the option that best fits your environment and upgrade status.

Option 1 — Upgrade to DataHub Cloud v0.3.14.1 or later (Recommended)
After upgrading, SCIM automatically handles pre-existing native users without manual intervention. No data loss occurs.
1. Contact DataHub support to schedule an upgrade to v0.3.14.1 or a later release.
2. Once upgraded, retry the SCIM push from Okta for any users that previously errored.
3. Verify that the affected users now show a successful provisioning status in Okta.
Option 2 — Manually set the origin aspect on pre-existing users (Preserves user data)
This approach updates each conflicting DataHub user record so that the SCIM endpoint recognises it as already SCIM-managed, allowing Okta to adopt the existing identity without recreating it. Data ownership and notification settings are preserved.
1. Collect the Okta User ID for each affected user from the Okta Admin Console. The ID has the format 00u<alphanumeric>.
2. For each user, emit an origin aspect to DataHub via the REST API. Replace the placeholders with real values:
```
POST https://<your-instance>.datahubproject.io/openapi/v3/entity/corpuser
Content-Type: application/json
Authorization: Bearer <your-datahub-pat>

{
  "urn": "urn:li:corpuser:<user-email>",
  "origin": {
    "type": "EXTERNAL",
    "externalType": "SCIM_client_<okta-client-id>"
  }
}
```
  The externalType value must match the SCIM client identifier shown in your Okta DataHub app configuration (e.g., SCIM_client_00u<okta-client-id>).
3. After setting the origin aspect, go to Okta and unassign the user from the DataHub application, then reassign them. This causes Okta to look up the user by username and adopt the existing DataHub record rather than generating its own UUID.
4. Important: Do not use Okta's Import / Match flow for these users. The match flow causes Okta to create its own UUID, which conflicts with the DataHub URN. Use direct assignment only.
5. Confirm in Okta that the user's provisioning status is now active and error-free.
6. Repeat for each conflicting user. If you have many users, a Python script that calls the Okta API to list users and their IDs, then emits the origin aspect to DataHub for each one, can automate steps 1–3 at scale.
Option 3 — Delete and re-provision (Simplest, but causes data loss)
Use this option only if preserving existing ownership, notifications, and permissions is not a concern, or if users' owned assets will be re-populated automatically by ingestion (e.g., via extract_owners: true in a source recipe).
1. Before deleting, export a record of each user's roles, group memberships, owned assets, and notification subscriptions.
2. Ensure at least one admin account will remain active after deletions to prevent lockout.
3. Delete the conflicting users from DataHub (Settings → Users & Groups, or via the DataHub CLI).
4. In Okta, trigger a SCIM push for those users. DataHub will create fresh SCIM-managed records.
5. Reassign roles and group-based permissions in DataHub as needed.

Additional Notes

Version fix: The root cause is resolved in DataHub Cloud v0.3.14.1+. If you are on an older version, Options 2 or 3 are required until an upgrade is possible.
Data preservation: Option 2 (manually setting the origin aspect) does not affect data ownership, notification subscriptions, or any other user metadata.
Going forward: To avoid this conflict on new deployments, configure SCIM provisioning in Okta before manually adding users to DataHub. Always add new users by assigning them to the DataHub Okta app first; SCIM will then provision them automatically.
Okta Import/Match flow: Avoid using Okta's built-in Import/Match feature when migrating pre-existing users to SCIM. Use direct Okta app assignment after the origin aspect has been set.
Asset re-population: If users own assets that were ingested with extract_owners: true, ownership will be restored on the next ingestion run even if users were deleted and re-provisioned.
Groups and roles: Group memberships and DataHub roles synced from Okta via SCIM must be re-assigned within DataHub after users are reprovisioned, unless role assignment is managed through Okta group mappings.