Hello Microsoft Support Team,

I am reaching out to request your assistance with an issue we are encountering in our direct federation setup with Microsoft Entra External ID (formerly Azure AD External ID). According to the Microsoft documentation (Direct Federation in Microsoft Entra ID), newer applications should utilize an SP entity ID that includes a tenant ID parameter for better isolation. However, in our current configuration, we are receiving a global SP entity ID (urn:federation:MicrosoftOnline) instead of the expected tenant-specific entity ID, such as https://login.microsoftonline.com/$tenant_id$/. We would like to migrate to a tenant-specific entity ID to align with our multi-tenant architecture and ensure proper isolation.

Background: We have successfully configured direct federation for our domain ([MASKED]) using the Microsoft Graph API, with Keycloak serving as our external Identity Provider (IdP). Below are the key details of our setup:

Domain: [MASKED] IdP Issuer URI: [MASKED] Sign-in URL: [MASKED] Current SP Entity ID: urn:federation:MicrosoftOnline (global) Desired SP Entity ID: A tenant-specific format, e.g., https://login.microsoftonline.com/$tenant_id$

We configured the federation using a PowerShell script with the Microsoft Graph API. Here is a masked version of the script for reference:

# Domain to federate
$domainId = '[MASKED]'

# SAML Issuer URI (Entity ID of the IdP)
$issuerUri = '[MASKED]'

# Sign-in URL (SSO Redirect URL)
$signinUri = '[MASKED]'

# Signing certificate (masked)
$cert = '[Masked certificate data]'

# Sign-out URL
$signoutUri = '[MASKED]'

# Display name
$displayName = '[MASKED]'

# Federation parameters
$domainAuthParams = @{
    DomainId = $domainId
    IssuerUri = $issuerUri
    DisplayName = $displayName
    ActiveSignInUri = $signinUri
    PassiveSignInUri = $signinUri
    SignOutUri = $signoutUri
    SigningCertificate = $cert
    PreferredAuthenticationProtocol = 'saml'
    FederatedIdpMfaBehavior = 'acceptIfMfaDoneByFederatedIdp'
}

# Apply federation
New-MgDomainFederationConfiguration @domainAuthParams

Problem Statement: When we examine the SAML AuthnRequest sent by Microsoft Entra to our IdP (Keycloak), the SP entity ID is consistently set to the global identifier urn:federation:MicrosoftOnline. Based on the documentation, we anticipated a tenant-specific SP entity ID, such as https://login.microsoftonline.com/$tenant_id$/, which would provide better isolation for our multi-tenant environment. Currently, the global entity ID does not meet our needs, as it does not differentiate between tenants, potentially leading to conflicts or misconfigurations in our architecture.

To summarize the issue:

Observed SP Entity ID: urn:federation:MicrosoftOnline (global) Expected SP Entity ID: https://login.microsoftonline.com/$tenant_id$/ (tenant-specific)

We have reviewed the Microsoft Graph API documentation and the New-MgDomainFederationConfiguration cmdlet, but we could not identify any parameters that allow us to specify or modify the SP entity ID. It appears that the SP entity ID defaults to the global value in our domain-level direct federation setup, and we are unsure how to configure it otherwise.

Request: We would like your guidance on the following:

1. Is it possible to configure a tenant-specific SP entity ID (e.g., https://login.microsoftonline.com/$tenant_id$/saml2) for our direct federation setup at the domain level?
   As mentioned here (https://learn.microsoft.com/en-us/entra/external-id/direct-federation#step-2-configure-the-partner-organizations-idp)
2. If this is supported, could you please provide instructions or point us to the specific configuration steps or API parameters needed to migrate from the global entity ID to a tenant-specific one?
3. If this is not currently possible, can you confirm this limitation and suggest any alternative approaches (e.g., SAML attributes or other mechanisms) to achieve tenant isolation in our federation setup?

Your expertise in resolving this matter would be greatly appreciated, as it is critical for aligning our federation configuration with our multi-tenant requirements.

Additional Information: Domain: [MASKED]

Thank you for your support, and we look forward to your response.

Best regards,

Romit