Forum Discussion

domi-b's avatar
domi-b
Copper Contributor
Aug 12, 2025

Can External ID (CIAM) federate to an Azure AD/Entra ID tenant using SAML?

What I'm trying to achieve

I'm setting up SAML federation FROM my External ID tenant (CIAM) TO a partner's Entra ID tenant (regular organizational tenant) for a hybrid CIAM/B2B setup where:

  • Business users authenticate via their corporate accounts (OIDC or SAML)
  • Individual customers use username/password or social providers (OIDC)

Tenant details / Terminology:

  • CIAM tenant: External ID tenant for customer-facing applications
  • IdP tenant: Example Partner's organizational Entra ID tenant with business accounts
  • Custom domain: mycustomdomain.com (example domain for the IdP tenant)

Configuration steps taken

Step 1: IdP Tenant (Entra ID) - Created SAML App

  • Set up Enterprise App with SAML SSO
  • Entity ID: https://login.microsoftonline.com/<CIAM_TENANT_ID>/
  • Reply URL: https://<CIAM_TENANT_ID>.ciamlogin.com/login.srf
  • NameID: Persistent format
  • Claim mapping: emailaddress → user.mail

Step 2: CIAM Tenant (External ID) - Added SAML IdP

(Initially imported from the SAML metadata URL from the above setup)

  • Federating domain: mycustomdomain.com
  • Issuer URI: https://sts.windows.net/<IDP_TENANT_ID>/
  • Passive endpoint: https://login.microsoftonline.com/mycustomdomain.com/saml2
  • DNS TXT record added: DirectFedAuthUrl=https://login.microsoftonline.com/mycustomdomain.com/saml2

Step 3: Attached to User Flow

  • Added SAML IdP to user flow under "Other identity providers"
  • Saved configuration and waited for propagation

The problem

It doesn't work. When testing via "Run user flow":

  • No SAML button appears (should display "Sign in with mycustomdomain")
  • Entering email address removed for privacy reasons doesn't trigger federation
  • The SAML provider appears configured but never shows up in the actual flow
  • Also tried using the tenant GUID in the passive endpoint instead of the domain - same result

My question

Is SAML federation from External ID to regular Entra ID tenants actually possible?

I know OIDC federation to Microsoft tenants is (currently, august 2025) explicitly blocked (microsoftonline.com domains are rejected). Is SAML similarly restricted? The portal lets me configure everything without throwing any errors, but it never actually works.

Am I missing something in my configuration? The documentation for this use case is limited and I've had to piece together the setup from various sources. Or is this a fundamental limitation where External ID simply can't federate to ANY Microsoft tenant regardless of the protocol used? 

2 Replies

  • You are very close, but the issue is likely not in your SAML configuration itself.

    External ID (CIAM) has specific limitations when the Identity Provider is another Microsoft Entra ID tenant. While the portal allows SAML configuration, Microsoft tenants are not always supported as external SAML IdPs in CIAM scenarios especially when using login.microsoftonline.com endpoints.

    If your goal is to allow corporate users from a partner tenant to authenticate using their work accounts, the recommended architecture is:

    • Use Microsoft Entra B2B between organizational tenants
      • Keep External ID (CIAM) for customer identities only

    CIAM is designed primarily for customer-facing authentication (local accounts, social IdPs, custom SAML IdPs), not as a federation bridge between Microsoft tenants.

    Also verify:

    • The domain is fully verified and marked as federated in CIAM
      • The issuer URI exactly matches the IdP metadata
      • The user flow supports domain discovery
      • The SAML IdP is properly assigned to the user flow

    However, if your IdP endpoint is login.microsoftonline.com, this may be a platform restriction rather than a configuration error.

  • bhavclaimer's avatar
    bhavclaimer
    Copper Contributor

    Hi! Did you end up with any idea or solution? I need to something similar - SAML or even Social Login, and it's quite bizarre that you can't use a Microsoft idp. I guess there are a few internal complexities sure, but you'd think this would be pretty out the box.