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.
\nThe Map identity provider groups to Docker teams documentation is the primary reference.
\nDocker’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.
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.
\nDSE 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.
\nFor 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.
\nReview 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.
\nClose 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.
\nProposed 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.
\nIf 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe Map identity provider groups to Docker teams documentation is the primary reference.\nDocker’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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nIs the connection SAML or Microsoft Entra ID OIDC?\nWhich mechanism should deliver the team-membership change?\nWhat exact organization and team should the group reference?\nWhich provisioning or sign-in observation will establish the actual result?\n\nDSE recommendation: name the membership route explicitly\nDSE 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.\nFor 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.\nReview 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.\nClose 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.\nVerification and evidence\nProposed 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.\nIf 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.\nOfficial references\n\nMap identity provider groups to Docker teams — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Map identity provider groups to Docker teams](https://docs.docker.com/security/provisioning/scim/group-mapping/) documentation is the primary reference.\n\nDocker’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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Is the connection SAML or Microsoft Entra ID OIDC?\n\n- Which mechanism should deliver the team-membership change?\n\n- What exact organization and team should the group reference?\n\n- Which provisioning or sign-in observation will establish the actual result?\n\n## DSE recommendation: name the membership route explicitly\n\nDSE 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.\n\nFor 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.\n\nReview 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.\n\nClose 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.\n\n## Verification and evidence\n\nProposed 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.\n\nIf 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.\n\n## Official references\n\n- [Map identity provider groups to Docker teams](https://docs.docker.com/security/provisioning/scim/group-mapping/) — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/use-scim-for-docker-group-mapping-with-entra-oidc/", "url": "https://update.dsesecurity.com/updates/use-scim-for-docker-group-mapping-with-entra-oidc/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/use-scim-for-docker-group-mapping-with-entra-oidc/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Use SCIM for Docker group mapping with Entra OIDC", "item": "https://update.dsesecurity.com/updates/use-scim-for-docker-group-mapping-with-entra-oidc/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/use-scim-for-docker-group-mapping-with-entra-oidc/#article", "identifier": "https://update.dsesecurity.com/updates/use-scim-for-docker-group-mapping-with-entra-oidc/", "url": "https://update.dsesecurity.com/updates/use-scim-for-docker-group-mapping-with-entra-oidc/", "headline": "Use SCIM for Docker group mapping with Entra OIDC", "description": "Docker does not support SSO group mapping through Microsoft Entra ID OIDC.", "abstract": "Docker does not support SSO group mapping through Microsoft Entra ID OIDC. Its guide directs those connections to SCIM, whose provisioning schedule is separate from SAML sign-in mapping.", "articleBody": "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.\nSource fact: documented behavior\nThe Map identity provider groups to Docker teams documentation is the primary reference.\nDocker’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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nIs the connection SAML or Microsoft Entra ID OIDC?\nWhich mechanism should deliver the team-membership change?\nWhat exact organization and team should the group reference?\nWhich provisioning or sign-in observation will establish the actual result?\n\nDSE recommendation: name the membership route explicitly\nDSE 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.\nFor 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.\nReview 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.\nClose 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.\nVerification and evidence\nProposed 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.\nIf 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.\nOfficial references\n\nMap identity provider groups to Docker teams — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T17:40:47+00:00", "dateModified": "2026-10-29T17:41:39+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/use-scim-for-docker-group-mapping-with-entra-oidc/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/use-scim-for-docker-group-mapping-with-entra-oidc/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Use SCIM for Docker group mapping with Entra OIDC" }, "articleSection": [ "IT", "Microsoft 365 & Identity" ], "keywords": [ "IT", "Microsoft 365 & Identity", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 541, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Docker Docs — Map identity provider groups to Docker teams", "url": "https://docs.docker.com/security/provisioning/scim/group-mapping/" } } ] } }