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.Protecting Workload Identities Using Conditional Access Policy in Entra
Hello Everyone, organizations around the world are implementing every possible measure to secure identities, ensuring that no user account bypasses additional checks like MFA or risk associated during sign-in. Microsoft Entra ID provides robust solutions to protect user identities. However, in my discussions with various organizations, I often find that many are unaware of the significant risks posed by unprotected workload identities. Workload identities are identities used by applications or services to access the resources they need in Azure. These include service principals, managed identities, and application registrations. One key distinction is that workload identities cannot have MFA enabled because they operate like a service account and enforcing MFA would severely disrupt application functionality. Additionally, application service principals sometimes use client secrets for authentication with Entra, posing a risk of credential leakage if placed at unprotected places. Furthermore, workload identities may be assigned high-privilege roles, increasing the risk to the entire identity environment if compromised. So, how can we protect workload identities effectively? Microsoft introduces Conditional Access Policies specifically designed for workload identities, focusing on service principals or applications as of now. To create a Conditional Access policy targeting workload identities, navigate to the Conditional Access policy section. However, you will notice that workload identities are not available as an assignment option by default. Activating this feature requires requesting a Microsoft Entra Workload Identities Premium license. By leveraging Conditional Access policies for workload identities, organizations can enforce security controls such as location-based restrictions, risk-based access decisions, and IP filtering for service principals. Implementing these policies helps mitigate the risks associated with compromised service accounts and strengthens the overall security posture of the identity infrastructure. Entra Workload Identities Premium License is available for trial and can be evaluated for 90 days with 200 licenses. Now, let’s take a deeper dive into how workload identities are protected. Once the Workload Identities Premium license is activated in an Entra tenant, it unlocks Conditional Access policy capabilities for workload identities. Key features offered include: Location-Based Protection Risk-Based Protection With these new Conditional Access policies, conditions such as location and service principal risk can be used to determine whether to grant or block access. For example, if service principal attempts to authenticate from an unknown location or if a service principal is flagged as risky, Conditional Access will enforce the actions defined in the policy. Entra Identity Protection also reports risky workload identities. It provides advanced threat detection and monitoring for workload identities, leveraging machine learning to detect unusual activities and potential security risks. If a service principal is compromised, it will be flagged as a risky workload Identities under Report section. I hope this provides clarity on why it is important to be concerned about how an applications or service principals can pose a significant risk to the environment if not properly protected.
