Datadog Multi-Org SAML SSO: Entity ID Limitation with Microsoft Entra ID

[Brakistad]

Datadog Multi-Org SAML SSO: Entity ID Limitation with Microsoft Entra ID

Executive Summary

When configuring SAML SSO for Datadog Enterprise multi-org environments using separate Microsoft Entra ID Enterprise Applications per child organization, IdP-initiated login functions correctly but the Datadog organization switcher fails. This is caused by a fundamental architectural mismatch between how Datadog and Microsoft Entra ID handle SAML Entity IDs.

---

Problem Statement

Functional Scenarios

Scenario	Result	Notes
IdP-initiated login via My Apps	Success	User clicks app tile, authentication succeeds
SAML Test in Entra ID	Success	Test authentication passes
Direct login to each child org	Success	Using org-specific Enterprise App
Datadog org switcher	Failure	"Assertion could not be validated"
SP-initiated cross-org login	Failure	"InResponseTo attribute missing"

---

Technical Root Cause

1. Datadog Uses a Single Entity ID for All Organizations

Datadog advertises the same SAML Entity ID for every organization, including parent and all children:

https://app.datadoghq.eu/account/saml/metadata.xml

This was verified via the Datadog API v2 SAML configurations endpoint. All organizations return the identical entity_id value.

2. Microsoft Entra ID Requires Unique Entity IDs

Entra ID enforces Entity ID (Identifier) uniqueness across Enterprise Applications within a tenant. When attempting to configure multiple Enterprise Apps with the same Entity ID, Entra ID rejects the configuration.

Customers are therefore required to use custom Entity IDs for child organization apps:

Enterprise App	Configured Entity ID (Entra ID)	Datadog Expected Entity ID
Datadog SSO (parent)	https://app.datadoghq.eu/account/saml/metadata.xml	https://app.datadoghq.eu/account/saml/metadata.xml
Datadog SSO - child-org-1	https://app.datadoghq.eu/saml/child-org-1	https://app.datadoghq.eu/account/saml/metadata.xml
Datadog SSO - child-org-2	https://app.datadoghq.eu/saml/child-org-2	https://app.datadoghq.eu/account/saml/metadata.xml
Datadog SSO - child-org-3	https://app.datadoghq.eu/saml/child-org-3	https://app.datadoghq.eu/account/saml/metadata.xml

The parent organization's Enterprise App owns the generic Entity ID. Child organizations cannot use it.

3. Entity ID Mismatch Causes Org Switcher Failures

When Datadog sends an SP-initiated SAML request via the org switcher, it includes:

<samlp:AuthnRequest 
    Issuer="https://app.datadoghq.eu/account/saml/metadata.xml"
    ...>

Entra ID looks up which Enterprise App has this Entity ID, finds the parent app, returns an assertion for the parent org, and the child org validation fails.

---

SAML Flow Analysis

IdP-Initiated Login (Successful)

1. User accesses My Apps Portal and clicks the child org application tile
2. Entra ID initiates the SAML flow from the child org Enterprise App
3. SAML Assertion is posted to the org-specific ACS URL:
   https://app.datadoghq.eu/account/saml/assertion/id/<child-org-public-id>
4. Datadog identifies the target organization from the URL path
5. Authentication succeeds

Why it works: The ACS URL contains the org-specific identifier. No Entity ID matching is performed for IdP-initiated login. Datadog identifies the org from the URL, not the SAML assertion.

SP-Initiated / Org Switcher (Failure)

1. User is logged into Child-1 and clicks the org switcher to select Child-2
2. Datadog sends a SAML AuthnRequest with Issuer: https://app.datadoghq.eu/account/saml/metadata.xml
3. Entra ID receives the AuthnRequest and looks up the Entity ID
4. Entra ID finds the parent app (which owns that Entity ID), not the Child-2 app
5. Entra ID responds with a SAML assertion configured for the parent org
6. Datadog Child-2 org receives an assertion with mismatched configuration
7. Validation fails with "Assertion could not be validated" or "InResponseTo attribute missing"

Why it fails: Datadog uses the same Entity ID for all organizations in SP-initiated flows. Entra ID routes the request to whichever app owns that Entity ID. The parent app owns it, resulting in an incorrect assertion being returned.

---

Business Requirements: Why Separate Enterprise Apps Are Required

Customers cannot use a single Enterprise Application for all Datadog organizations. This is not a preference but a regulatory and security requirement.

Information Barrier Policy

Organizations operating multiple business units may be subject to strict information flow prevention policies requiring:

1. Data Segregation: Each business unit's monitoring data must be isolated in separate Datadog organizations
2. Access Control at IdP Level: User access to each organization must be controlled and auditable at the Identity Provider level
3. Principle of Least Privilege: Users should only have access to the specific organizations they require

This is the primary reason customers select Datadog's Enterprise multi-org feature with separate child organizations.

SCIM Provisioning Requirements

Using a single Enterprise Application renders SCIM provisioning ineffective for granular access control:

Requirement	Single App	Separate Apps
Different users per org	Not possible	Supported
Automated user provisioning per org	Not possible	Supported
Automated user deprovisioning per org	Not possible	Supported
Group-based access per org	All users access all orgs	Granular control
Audit trail per org	Combined	Separate

With a single Enterprise App, all users assigned to the app would be provisioned to all organizations. There is no mechanism to restrict User A to Org-1 while restricting User B to Org-2. SCIM provisioning would create users in every organization, violating information barrier policies.

Compliance Implications

Using a single Enterprise Application would result in:

1. Compliance Violations: Users from one business unit could access monitoring data from another business unit
2. Audit Failures: Organizations could not demonstrate proper access segregation to auditors
3. Security Risk: Lateral movement between organizations would be possible

Using a single Enterprise App is not viable for organizations with information barrier requirements or per-org access control needs.

---

Current Workaround

Use IdP-initiated login exclusively:

• Users access child organizations via the My Apps Portal
• Each organization has its own application tile
• The org switcher is non-functional; users must use My Apps to switch organizations

Advantages:

• Functional without additional configuration
• Supports different user assignments per organization
• Enables granular access control per organization
• SCIM provisioning functions correctly per organization
• Satisfies information barrier requirements

Disadvantages:

• Users cannot use Datadog's built-in org switcher
• Requires users to bookmark My Apps or use application tiles
• Degraded user experience compared to native org switching

---

Proposed Solution: Unique Entity ID per Organization

The recommended solution is for Datadog to support unique Entity IDs per organization:

Organization	Proposed Entity ID
Parent	https://app.datadoghq.eu/account/saml/metadata.xml
Child Org 1	https://app.datadoghq.eu/account/saml/metadata.xml/child-org-1
Child Org 2	https://app.datadoghq.eu/account/saml/metadata.xml/child-org-2

Alternatively, using the organization's public_id:

Organization	Proposed Entity ID
Child Org 1	https://app.datadoghq.eu/account/saml/metadata.xml/<org-public-id>

This would enable:

• Separate Enterprise Apps per organization in Entra ID (required for SCIM)
• Functional org switcher
• Granular access control at IdP level
• SCIM provisioning scoped per organization
• Compliance with information barrier policies

This is the only viable long-term solution for enterprises with strict access control requirements.

---

Feature Request Summary

We request that Datadog implement unique SAML Entity IDs per organization to support enterprise customers who:

1. Use Microsoft Entra ID (Azure AD) as their Identity Provider
2. Require separate Enterprise Applications per child organization for:
   • SCIM provisioning
   • Granular access control
   • Information barrier compliance
   • Audit requirements

The current architecture where all organizations share the same Entity ID (https://app.datadoghq.eu/account/saml/metadata.xml) is incompatible with Entra ID's requirement for unique Entity IDs per Enterprise Application.

Impact: The org switcher feature is unusable for customers with these requirements, degrading the user experience and necessitating workarounds via IdP-initiated login only.

---

References

Datadog Documentation

1. SAML Configuration Guide

   • https://docs.datadoghq.com/account_management/saml/

2. IdP-Initiated Login

   • https://docs.datadoghq.com/account_management/saml/#idp-initiated-login
   • Reference: "After enabling the IdP-initiated login feature... your new SP metadata contains a different, organization-specific AssertionConsumerService endpoint"

3. Multi-Organization Accounts

   • https://docs.datadoghq.com/account_management/multi_organization/

Microsoft Documentation

4. Enterprise App Unique Identifiers
   • https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/add-application-portal-setup-sso
   • Entra ID requires unique Entity IDs per Enterprise Application

SAML Specification

5. OASIS SAML 2.0 Core Specification
   • http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
   • Section 8.3.6: Entity Identifiers must be globally unique