Entra ID SAML Federation with an External Identity Provider
SAML Federation of Entra ID with an External Identity Provider In today’s interconnected world, organizations frequently collaborate with external partners, vendors, and customers while ensuring secure access to their resources. Microsoft Entra ID provides a robust solution for secure authentication and authorization across organizational boundaries. One of the key features enabling this is SAML Federation, which allows Entra ID to integrate with external identity providers (IdPs) using SAML 2.0 or WS-Federation protocols. In this blog, we’ll explore how to set up SAML Federation between Entra ID and an external IdP, enabling users from the external organization to access your applications seamlessly using their own credentials. What is SAML Federation? SAML/WS-Fed Federation is a feature in Microsoft Entra ID that establishes a trust relationship with an external identity provider. This trust allows users from the external IdP to authenticate directly using their own credentials. This approach is particularly useful for scenarios such as: Collaborating with external partners who use their own identity systems. Allowing customers to access your applications using their existing credentials. Simplifying user management by leveraging external identity providers. SAML/WS-Fed Federation supports both SAML 2.0 and WS-Federation protocols, making it compatible with a wide range of identity providers. Key Concepts of SAML/WS-Fed Federation: Before diving into the setup process, it’s important to understand a few key concepts: External Identity Provider (IdP): The identity system used by the external organization to authenticate its users. Relying Party (RP): The application or service in your Entra ID tenant that external users will access. Federation Metadata: A file or URL provided by the external IdP that contains configuration details, such as endpoints and certificates, required to establish the trust relationship. Domain Name: If passive authentication domain name associated with the external IdP (e.g., spintoys.com) is same, in that case no DNS changes are required. However, if passive authentication domain is different, lets says myspintoys.com, then in that case a TXT record should be created in spintoys.com domain in the format “spintoys.com. IN TXT DirectFedAuthUrl=https://myspintoys.com.” The TXT record acts as proof that the domain owner intentionally set up federation with an external IdP. How to Set Up Federation in Entra ID with External IDP: In this blog, we will demonstrate federation setup using Okta as an external identity provider. The process is similar for other SAML-based identity providers as well. Step 1: Create an Application in the External IdP (Okta) Before configuring Entra ID, we must create an application in Okta or other External IDP Provider with which we want to establish federation: Log in to Okta Admin Console with an account that has permissions to create applications. Navigate to the Applications section and click “Create App Integration.” Choose SAML 2.0 as the integration type and click Next. Provide an Application Name under General Settings and Click Next. Under SAML Settings, enter: Single Sign-On URL: https://login.microsoftonline.com//saml2 Recipient & Destination URL: Same as the Single Sign-On URL. Audience Restriction: urn:federation:MicrosoftOnline Name ID Format: Unspecified Application User Name: None We can set “Name ID Format” as unspecified, & Application User Name as none. Next, we need to add attributes or claims which External IDP in this case Okta will send to Entra ID after user authenticated. So, add http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress. Name Format as unspecified and Value is “user.email”. Next if we also want to send mfa claims, we can add one more attribute http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod Name Format as unspecified and Value is http://schemas.microsoft.com/claims/multipleauthn Click Next, review the settings, and Finish the application registration. The application registered in Okta will provide us with the IdP, SSO URL, IdP Issuer URL, certificate, and IdP metadata required to create a SAML federation in Entra ID. Extract this information from the application. Open the Application created above and go to the sign-on section. We will find an option to view SAML Setup Instruction which will provide us with all the above details. Click on View SAML Setup Instructions and it should show us all the required details. Step 2: Adding a SAML Identity Provider in Entra: Once we noted down all the above details. Sign-in to Entra Portal and Go to External Identities. Sign in to the Entra portal and navigate to External Identities. Click on All Identity Providers, then select Custom, click Add New, and choose SAML/WS-Fed. Enter a Display Name of your choice. Under Identity Provider Protocol, select SAML. Under Domain Name of Federating IdP, enter the domain registered in public DNS. If using a different domain, ensure a TXT record is added to the registered DNS domain. Under Select a method for populating metadata, choose Input metadata manually. I am only demonstrating how we can establish this Federation. However, there is risk of updating federation setting in Entra ID manually is that when certificate expires, it must be manually updated with new one. If we select option “Parse metdata file” this will ensure that certificate is updated by connecting metadata of External IDP. Enter the details captured in step 13 into the respective fields. Under Issuer URI, enter the value retrieved from Identity Provider Issuer in Okta. Under Passive Authentication Endpoint, enter the Identity Provider Single Sign-On URL from Okta. Under Certificate, copy and paste the certificate from the View SAML Setup Instructions page in Okta. Finally, enter the Metadata URL retrieved from the same SAML setup page. Step 3: Testing SAML Federation Setup: To verify if the SAML federation has been successfully configured, follow these steps: Invite a Guest User in Entra ID Invite a guest user from the external IdP (Okta) into Entra ID. Allow the user to redeem the invitation. If the user does not have a valid email, you can skip the email invitation link for redemption. Ensure Application Access in Okta The application created in Okta must be accessible to all users who will be invited to Entra ID. Assign the application in Okta to these users to ensure they can authenticate Assign Access in Entra ID On the Entra ID side, grant the guest user access to the target application. This can be any application, such as a SAML-based or OAuth2-based application. Perform Sign-in Test Open the application registered in Entra ID and sign in as the guest user. Realm Discovery in Entra ID will check federation settings and redirect the user to their home IdP (Okta) in this example for authentication. Once authenticated, Okta will send SAML assertions or claims to Entra ID, including user.email and MFA claims (if configured) I have captured SAML traces to show how claims are flowing between Entra ID and Okta In this picture, I tried to access https://xyz1234.zohodesk.in/portal application registered in Entra ID Here, request is redirected to https://login.microsoftonline.com for authentication Okta issued two claims, emailaddress and mfa. Finally, Entra ID issued multiple or all required claims to Zoho Application for authorization. 4. Validate Access After authentication, Entra ID redirects the user back to the target application. If the correct permissions are in place, the user should sign in successfully. Important Note: Entra ID does not forward or share SAML assertions received from the external IdP directly with the application. Instead, Entra ID extracts claims from the attributes of the guest user profile in Entra ID. If the application accessed by the guest user requires specific attributes that are not configured in Entra ID, authorization may fail. Ensure that the necessary attributes are properly mapped and available in Entra ID to avoid access issues. It is also important to note that any domain name with which the federation is being created should not be registered domain in Entra ID, else federation will fail. Benefits of Direct Federation: Seamless User Experience: External users can sign in to your applications using their existing credentials, reducing friction and improving adoption. Reduced Administrative Overhead: You don’t need to manage accounts for external users in your Entra ID tenant like Password or MFA etc. Enhanced Security: We can apply Conditional Access Policy on Guest users to enhance security. Best Practices for SAML Federation: Validate the External IdP’s Security Posture: Ensure the external IdP adheres to security best practices, such as enforcing strong authentication and regular security audits. Monitor and Audit Access: Use Entra ID’s logging and monitoring capabilities to track sign-ins and detect any suspicious activity. Provide Clear Documentation: Share detailed instructions with external users on how to access your applications using their IdP credentials. Conclusion: Implementing SAML/WS-Fed Federation in Microsoft Entra ID provides a seamless and secure authentication experience for external users. By establishing a trust relationship with an external Identity Provider (IdP), organizations can enable partners and customers to access applications using their existing credentials, reducing the need for managing separate accounts. This federation enhances security, reduces administrative overhead, and improves user experience. By carefully configuring claims, authentication policies, and domain validation, businesses can ensure that authentication flows smoothly while maintaining strong security controls. By following the steps outlined in this guide, you can successfully set up SAML/WS-Fed Federation with an external IdP, improving collaboration while maintaining security and compliance. I hope you found this blog helpful. I will come back with more interesting blogs soon.
Azure AD Direct Connect access denied
Hi. We've set up Direct Connect for the first time between two of our tenants. We've configured the External Identities -> Cross-tenant access settings exactly the same on both. But on both we get this error message when attempting to access a Sharepoint site from each tenant: Here're the settings (same for both tenants): I cannot figure out why access would be blocked as these settings seem to be the most permissive possible. Thanks for your help.
