Use SCIM for Docker group mapping with Entra OIDC

Bottom line: Choose the group-membership route from the identity connection actually in use. Keep authentication and team synchronization visible as separate parts of the access procedure instead of assuming that a successful sign-in has applied the intended group change.

Source fact: documented behavior

The Map identity provider groups to Docker teams documentation is the primary reference.

Docker’s guide says SSO group mapping is not supported with Microsoft Entra ID OIDC and directs those connections to SCIM group synchronization. The guide distinguishes SAML group membership sent at sign-in from SCIM group membership synchronized on the identity provider’s provisioning schedule. The documented group format is organization:team, and a mapped group can create a team that does not already exist. The page identifies Docker Business and administrator use, with configured SSO and administrator access to Docker Home and the identity provider as prerequisites.

What the source does not establish

This article reviews the documented membership route and target naming. It does not approve a subscription, grant application access universally or establish how every identity provider handles removal and retries. Keep role assignment, account lifecycle and the actual provisioning service’s operational requirements in separate reviewed procedures.

Applicability questions

• Is the connection SAML or Microsoft Entra ID OIDC?
• Which mechanism should deliver the team-membership change?
• What exact organization and team should the group reference?
• Which provisioning or sign-in observation will establish the actual result?

DSE recommendation: name the membership route explicitly

DSE recommends recording the authentication method and membership mechanism in separate fields in the integration runbook. Have the identity and Docker administrators confirm both before troubleshooting a missing team assignment. Keep the actual subscription and prerequisite checks attributable to the responsible owners.

For the Entra OIDC case, review the documented SCIM setup rather than repeatedly changing a SAML group claim. Identify the provisioning owner, assigned application and expected observation window. Do not promise an immediate membership change merely because the user can sign in.

Review group names as access targets. Write the intended organization and team beside each approved mapping, and have the Docker owner check unexpected team creation as deliberately as missing membership. Use a clearly labeled test group and identity for the first exercise. Keep unrelated production users outside the test assignment.

Close the membership change against observations from both ends. Compare the intended assignment with provisioning records and the actual Docker team membership. Resolve an incorrect target or unobserved change before extending the assignment. Keep role permissions and deprovisioning acceptance outside a sign-in-only check; those require their own reviewed outcomes.

Verification and evidence

Proposed verification, not performed: use an authorized test identity and one harmless organization-team mapping. Record the authentication method, membership route and expected target before assignment. For SCIM, inspect the actual provisioning result and Docker membership within the agreed observation process.

If a SAML comparison is relevant and separately authorized, record its sign-in-triggered mapping as a different case. Do not switch production authentication merely to create a comparison. Retain redacted group names where necessary, selected route, observed timestamps and membership evidence. Mark any untested removal or role behavior as a separate unresolved requirement.

Official references

• Map identity provider groups to Docker teams — Docker Docs.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.