B2B Collaboration Non-Entra Identity Providers

Entra ID External Identities only supports SAML 2.0 and WS-Federation protocols for custom identity provider federation. If the partner's IdP uses a different protocol (e.g. OAuth-only, LDAP, or proprietary), federation cannot be established through this method. Confirming protocol compatibility first avoids wasted effort on both sides.

Entra ID requires that the partner's passive authentication endpoint URL domain matches the domain portion of their users' UPNs (email addresses). This is a security measure — it ensures R&R's tenant is redirecting authentication to a URL that is verifiably controlled by the same organisation that owns the users' email domain. A mismatch will cause federation to fail.

If the partner's passive authentication endpoint is hosted on a different domain to their users' UPNs (e.g. users are @example.com but the IdP endpoint is at example.co.uk), a DNS TXT record must be added to the UPN domain's DNS zone. This record tells Entra ID that the domain owner has explicitly authorised the cross-domain authentication endpoint — it is a domain ownership verification mechanism that prevents spoofing.

For federation to work, the partner's IdP must be configured to issue SAML assertions or WS-Fed tokens containing the specific attributes and claims that R&R's Entra ID expects. The onboarding document (External IdAM – Onboarding Document (For Suppliers)) provides the partner's IT team with the exact technical requirements — including the claims schema, expected issuer URI format, and signing certificate requirements. Without this, the partner's IdP tokens will be rejected by Entra.

Before configuring federation in Entra, you need the partner's technical IdP details. These are the cryptographic and endpoint values that allow R&R's Entra to verify that incoming authentication tokens are genuinely issued by the partner's IdP and have not been tampered with. Without these, Entra cannot establish a trust relationship.

Custom federation partners are managed under Entra ID → External Identities → All Identity Providers. You must sign in with a PRV account elevated to External Identity Provider Administrator — this role specifically governs the ability to create and manage federation trusts with non-Microsoft identity providers.

This is the core configuration step — you are creating a federation trust between R&R's Entra ID tenant and the partner's identity provider. Once saved, Entra will recognise the partner's IdP as a trusted authentication source, meaning guest users from that organisation can accept B2B invites and authenticate with their home identity rather than needing a Microsoft account or one-time passcode. Every field links back to a cryptographic or routing requirement that ensures tokens are verified and users are directed to the correct authentication endpoint.

When a partner organisation does not use Entra as their IdP but has an Entra-verified domain (e.g. they own the domain in an Entra tenant they don't actively use for authentication), a conflict arises. By default, Entra tries Entra-to-Entra federation first — which would fail because the partner doesn't actually authenticate users through their Entra tenant. The redemption order must be updated so that custom SAML/WS-Fed providers are evaluated before Entra trust, ensuring users are routed to the correct IdP.

The redemption order defines the priority sequence Entra follows when determining how an invited guest user should authenticate. By moving SAML/WS-Fed Identity Providers higher in the order, you ensure custom federation is evaluated before Entra-to-Entra trust — correctly routing users to their actual IdP. This is a one-off, tenant-wide configuration that only needs to be done once, and it applies to all future B2B invitations.