Summary
In Artifactory, there are no constraints on the number of simultaneous SCIM connectors pushing data, provided they utilize a valid admin-scoped token. When migrating between Identity Providers, such as transitioning from Okta to Microsoft Entra or running both concurrently, existing groups are not deleted, replaced, or duplicated.
Group names serve as the unique identifier across all IdPs. However, group membership can be impacted, as the outcome depends on whether the new IdP references the group and the specific update operations it executes.
Group identity: no per-IdP namespace
Groups are identified solely by their names across the entire system. A group initially created via Okta and later targeted by Entra under the same name is treated as a single entity; there is no internal metadata distinguishing the source IdP (see Manage Groups). A Create Group request for an existing name will fail rather than duplicate. Consequently, a standard SCIM client must identify the existing group via name or filter and then apply updates or patches, as detailed in the SCIM documentation.
Net effect: The group entity and its associated permission assignments remain intact and are not overwritten or duplicated when a second IdP provisions under an identical name.
Group membership: request-driven, not reconciled in the background
SCIM logic is only triggered by specific connector requests; there is no automatic background reconciliation when switching sources.
-
If the new IdP does not reference a specific group (due to missing matching names or lack of management for that user), its membership remains unchanged.
-
If the new IdP issues a PUT or a PATCH with a replace operation on members: The incoming list becomes the definitive membership. Any current members missing from this new payload are removed.
-
If the new IdP issues a PATCH with specific add/remove commands: Only the explicitly mentioned users are modified, leaving all other memberships untouched.
Practical guidance: It is highly recommended to test the migration with a single non-essential group first. Since the exact behavior of an IdP's SCIM connector cannot be verified from the Artifactory side, compare the new IdP's membership data against existing records before a full rollout.
Running two SCIM connectors in parallel during a migration
Enabling a new IdP's SCIM connector does not require deactivating the existing one.
Caveat: Operating parallel connectors on the same users or groups risks conflicting membership updates. We suggest using dedicated test objects for validation to avoid disrupting data provisioned by the original IdP.
To retire the legacy IdP token, navigate to the Access Tokens page in the UI to revoke it, or utilize the Revoke Token by ID REST API.