Forum Discussion
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?
4 Replies
- IdentitySecuristCopper Contributor
The issue isn't with your SAML configuration. The limitation is that External ID (CIAM) doesn't support federating to Microsoft Entra ID (organizational) tenants as an external identity provider using SAML.
The reason the configuration is accepted in the portal is that the SAML IdP configuration itself is valid, but the sign-in experience doesn't treat another Microsoft Entra tenant as a supported external SAML identity provider. As a result:
- The SAML provider doesn't appear in the user flow.
- Home Realm Discovery isn't triggered for the Entra domain.
- Entering a corporate email address doesn't initiate federation.
If your goal is to allow users from another Entra tenant to sign in, the supported approach is to use Microsoft Entra B2B collaboration (guest users) rather than attempting to federate the partner's Entra tenant into your External ID tenant.
If you need true federation with SAML, the IdP must be a supported third-party SAML identity provider (for example, ADFS, PingFederate, Okta, Shibboleth, etc.), not another Microsoft Entra ID tenant.
If this resolves your issue, please consider marking the answer as the solution so it can help others facing the same problem.
I used this guide to test and it works correctly.
Add Microsoft Entra ID for customer sign-in - Microsoft Entra External ID | Microsoft Learn
I configured Microsoft Entra ID as my federated identity provider, but it doesn't appear on the sign-in page. What should I check?
Verify that the issuer URI and well-known OpenID configuration endpoint are correctly configured. An incorrect issuer or discovery endpoint prevents the identity provider from appearing during sign-in. Also check that:
- The Microsoft Entra ID tenant is fully configured as a custom OIDC identity provider.
- Required redirect URIs, issuer values, and scopes are present and correct.
- The identity provider is added to the user flow, not just to the tenant.
- Configuration changes have fully propagated. Re-saving or recreating the user flow after configuration changes often resolves this issue.
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.
- Use Microsoft Entra B2B between organizational tenants
- bhavclaimerCopper 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.