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.Passkeys Authentication Across Platforms and Devices using Entra ID
Hello Everyone, In this blog, we will explore passkeys, a phishing-resistant, Passwordless authentication method based on the Fast Identity Online (FIDO2) standard, now available in Entra ID. With the constantly evolving security threat landscape, passwords combined with multi-factor authentication (MFA) are no longer sufficient. Stronger, more secure authentication methods are essential to address modern security challenges. Microsoft has been at the forefront of this evolution, introducing Windows Hello for Business in 2015 and expanding Passwordless options with FIDO2 authentication in 2019. Additionally, the Microsoft Authenticator App with phone sign-in offered a convenient Passwordless solution. However, this method lacked phishing resistance due to its inability to guarantee proximity between the user's device and the authenticator app. This gap may left users vulnerable to social engineering attacks where attackers could deceive users into entering codes. To combat such risks, phishing-resistant Passwordless authentication methods, including enhanced support for Microsoft Authenticator, have become critical. Picture above depict how an attacker can persuade user to authenticate using authenticator app. How Passkeys Registration and Authentication Work Across Devices and Platforms Passkeys work by leveraging public-key cryptography (PKI) for authentication, providing a seamless and secure login experience across devices and platforms. Let’s break down how passkeys operate in real-world scenarios and their cross-platform advantages. Let’s begin by understanding how the registration of a passkey works. When a user accesses a website or Relying Party (RP), such as www.linkedin.com , that supports passkeys from a Windows client via a browser, the website or RP sends a nonce (a one-time random value) to the browser. The browser, running on the client device, forwards that nonce to the authenticator, in this case, the Microsoft Authenticator App. The client prompts the user to select an authenticator. The user can choose another device, such as an iPhone, iPad, or Android device running the Microsoft Authenticator App, or a physical security key. The authenticator generates a key pair: a public key and a private key. It also provides an option for storing the keys, such as in iCloud Keychain, Google Password Manager, or the Microsoft Authenticator App. The private key is securely stored within the authenticator and is used to sign the nonce. The signed nonce, along with the public key, is sent back to the browser, which forwards it to the website or RP (www.linkedin.com ) for storage. This completes the passkey registration process. Now, let’s understand how the authentication process works. When the same user accesses the same website or RP (www.linkedin.com ) for which they registered the passkeys, from a Windows client device using a browser, the system checks if the website’s domain matches the Relying Party ID (RPID). A component within the browser called Web Authentication (WebAuthN) ensures that the website URL and the RPID match. If no match is found, the process is halted. If a match is found, the website sends a nonce to the browser, which forwards it to the authenticator to further process authentication. If a user selects authenticator on another device like iPhone or Android device, browser shows a QRCode on screen for User to scan. This QRCode has information about the website or RP user is accessing. When User scans the QrCode in authenticator, it detects the passkey in authenticator and asks user to select. When the user opens the Microsoft Authenticator App on their mobile phone, and the Windows client device establishes proximity with the mobile device using either NFC, Bluetooth, or USB. This connectivity, referred to as the Client to Authenticator Protocol (CTAP), ensures secure communication. The user is then challenged with biometric to unlock the private key stored in authenticator and sign the nonce. The signed nonce is returned to the browser, which forwards it to the website or RP to complete the authentication process. If you observe closely, the user is accessing website or RP from Windows client device and authenticator is running on either iPhone or Android. This process not only enables passkey authentication across devices, but it also allows cross-platform functionality. Additionally, WebAuthN provides an extra layer of security by verifying the website’s URL against the RPID, protecting against phishing attacks. I hope you found this article informative. I will be back soon with more interesting article on Microsoft Entra ID.Leveraging Custom Security Attributes in Conditional Access Policies
Microsoft Entra ID provides robust tools for managing access to resources through Conditional Access (CA) policies. However, some service principals representing certain resources cannot be directly included in CA policies. To address this, we can use custom security attributes to control access to these resources. This blog will guide through the process of creating and applying custom security attributes to service principals, enabling or blocking them through Conditional Access policies. Understanding the Challenge: Service principals often represent applications or resources within Azure environment. While Conditional Access policies are excellent for enforcing access controls, certain service principals cannot be directly targeted. This necessitates an alternative approach to apply CA policies to such resources. By using custom security attributes, we can create a flexible and manageable solution to include these service principals in our Conditional Access strategy. Steps to Use Custom Security Attributes for Service Principals: Add a new custom security attributes allow us to tag service principals so that it can be used in Conditional Access policies. To begin, define a custom security attribute using PowerShell. Example of PowerShell Command: # Create a new custom attribute definition from PowerShell $params = @{ Id = "HR" Description = "Attributes for HR team" MaxAttributesPerSet = 25 } $customSecurityAttributes = New-MgDirectoryAttributeSet -BodyParameter $params Create service principal for the resource which we want to control # Create a new service principal $servicePrincipal = New-MgServicePrincipal -AppId <AppId> Assign the Custom Security Attribute to a Service Principal once the custom security attribute is created. # Assign the custom security attribute to the service principal Update-MgServicePrincipal -ServicePrincipalId $ServicePrincipal -CustomSecurityAttributes $customSecurityAttributes Configure Conditional Access Policy to evaluates the custom attribute. Open the Entra admin center. Navigate to Security > Conditional Access. Create a new policy and define its scope like All Users or Groups. In the Target resources section, use select resources. Click on Edit Filter and select custom security attributes created above Test the Policy to validate that the Conditional Access policy behaves as expected: Attempt access to the resource represented by the service principal. Verify that access is either allowed or blocked based targeted resource and grant control Real-World Use Case: Imagine we have an application represented by a service principal, which handles sensitive operations. However, this service principal is not available for direct inclusion in a Conditional Access policy. By assigning a custom security attribute to the service principal, we can: Enforce stricter access controls. Block or allow access based on the defined Conditional Access policy. This approach not only addresses the limitation of directly targeting service principals but also provides a scalable way to manage access for multiple resources. Conclusion: Custom security attributes empower administrators to leverage Conditional Access policies for such service principals. By tagging service principals with custom security attribute in CA policies, we gain finer control over access to critical resources. This method is especially useful for resources that cannot be directly added to CA policies, ensuring our organization's security and compliance requirements are met efficiently. Start exploring custom security attributes today to enhance your Conditional Access strategy and secure your Azure environment effectively!Enhancing Security with Entra PIM and Conditional Access Policy using Authentication Context
In today’s cybersecurity landscape, organizations face an ever-evolving set of threats targeting privileged accounts. These accounts often have elevated permissions, making them a high-value target for attackers. To mitigate these risks, Microsoft Entra’s Privileged Identity Management (PIM) and Conditional Access Policies offer robust solutions to manage, monitor, and secure privileged access. When combined with Authentication Context, organizations can adopt a highly granular approach to securing their resources, ensuring compliance with the Zero Trust security model. What is Privileged Identity Management (PIM)? Privileged Identity Management (PIM) is a feature in Microsoft Entra that enables organizations to manage and control access to critical resources by: Assigning just-in-time (JIT) access to Azure AD roles, Azure resources, and Groups. Enforcing approval workflows for privileged access. Automatically expiring access after a set duration. Providing audit logs and alerts for suspicious activities. PIM ensures that privileged access is temporary, controlled, and auditable, reducing the attack surface of highly sensitive accounts. Conditional Access Policies: Adding a Layer of Security Conditional Access Policies are the backbone of modern identity security in Microsoft Entra. These policies allow organizations to enforce granular access controls based on: User or group identities. Device compliance. Risk levels. Location or IP ranges. Authentication Contexts. Conditional Access ensures that access to resources is granted only under secure conditions, further reinforcing the Zero Trust principle of “Never Trust, Always Verify.” What is Conditional Access Authentication Context? Authentication Context adds an additional dimension to Conditional Access Policies by defining specific access scenarios. These scenarios can then be tied to Conditional Access Policies to enforce elevated security requirements for sensitive actions or resources. For example, you can require multi-factor authentication (MFA) or device compliance for users accessing sensitive files or approving PIM role activations. Combining PIM with Conditional Access Using Authentication Context By integrating PIM and Conditional Access with Authentication Context, organizations can: Elevate Security for Privileged Role Activation: Require additional verification steps, such as MFA or specific device compliance, trusted location before activating privileged roles in PIM. Define Authentication Context for role activation to enforce conditional access policies tailored to sensitive scenarios. Enforce Session Controls: Use session controls to monitor and limit privileged activities during active sessions, ensuring users do not exceed their assigned tasks. Ensure Compliance with Regulatory Standards: Authentication Context can help align role activation processes with specific compliance requirements, such as GDPR or HIPAA, by enforcing strict security controls. Use Case: Applying Authentication Context to PIM Role Activation Let’s explore a practical example: Scenario: An administrator wants to activate the Global Administrator role in PIM to make a critical change in the organization’s configuration. Configuration Steps: Define Authentication Context: Create an Authentication Context labeled “Privileged Role Activation” with specific security requirements like MFA, compliant device, a high-risk block policy or trusted location. Create a Conditional Access Policy: Tie the Authentication Context to a Conditional Access Policy that applies to the “Privileged Role Activation” scenario. Integrate with PIM: When the administrator requests activation of the Global Administrator role, they must satisfy the Conditional Access requirements defined in the Authentication Context. Outcome: Only users meeting the stringent security criteria can activate privileged roles, ensuring robust protection against unauthorized or risky activations. Benefits of This Integration Granular Access Control: Authentication Context allows for tailored Conditional Access Policies specific to PIM scenarios, reducing blanket enforcement. Enhanced User Experience: Security controls are applied contextually, ensuring users face additional challenges only when necessary. Improved Auditing and Monitoring: Every privileged role activation is tied to an Authentication Context, providing detailed logs for compliance and forensic analysis. Alignment with Zero Trust: Combines PIM’s JIT access with the robust security of Conditional Access, ensuring that no access is granted without verification. Conclusion The integration of Privileged Identity Management, Conditional Access Policies, and Authentication Context offers a powerful solution for managing privileged access in a secure, controlled, and compliant manner. By requiring additional authentication and compliance checks for privileged role activations, organizations can significantly reduce their attack surface while maintaining operational agility. This approach aligns perfectly with the Zero Trust model, ensuring security at every step of the access lifecycle. Start implementing these features today to strengthen your identity and access management strategy!Entra ID Continuous Access Evaluation unfold
I am Farooque Mohammad, and I have been working with Microsoft for the last 6.5 years. I primarily work on Identity & Security. This is my first blog, and I want to dive into Entra ID Continuous Access Evaluation (CAE), a security feature that helps protect resources on Entra ID. Assume a client wants to access a resource or an application. It requires authentication to receive two tokens: Refresh and Access. The Refresh Token is valid for up to 14 days or more, while the Access Token lasts for 60 to 90 minutes. The client must obtain a new Access Token approximately every hour using the Refresh Token. Now, what happens if the Access Token is compromised or stolen? It will remain valid for an hour, providing an attacker ample time to stay active in the system. In such cases, we need a mechanism to invalidate or revoke it when a critical event occurs. For example: User password is changed or reset. User account is disabled or deleted. Location changes. MFA is enabled for the user. The user’s token is explicitly revoked. A high user risk is detected via Entra ID Protection. When one of these critical events is triggered, Entra ID sends a revocation event to the application or resource. This invalidates the current token and prompts the application or resource to respond with a 401 challenge, requesting the client to authenticate again. The client sends its Refresh Token along with the challenge to obtain a new Access Token, which is issued by Entra ID. This process ensures that, within 15 minutes of a critical event, the compromised token is replaced with a new one. It is important to note that both the client and resource must support CAE for this mechanism to work. As of now, Exchange Online, SharePoint, OneDrive, Teams, and Graph API are CAE-capable, and more services will be added in the future. Another benefit of CAE is its additional checks for IPv4 and IPv6 locations. When a client requests access, Entra ID evaluates the Conditional Access Policy for the resource and appends a Conditional Access Policy ID (CAPID) to the token. The resource or application can then validate this information by querying Entra ID for the allowed IP range. If the client changes its location, the resource or application detects this mismatch and issues a 401 challenge, prompting the client to obtain a new token. This prevents access when the token is used from unauthorized locations, even if stolen. CAE is enabled by default, provided both the client and resource support it. Conditional Access policies under session control also offer customization, such as disabling CAE or strictly enforcing location policies. Enabling the strict enforcement option may disrupt access if traffic routes through different IPs. For instance, consider a scenario where Client1's request initially passes through a network firewall with IP 193.20.1.10. When the same token is used to access Exchange Online, the traffic might route through a different IP, such as 193.30.1.20, causing a block because the resource expects traffic from the original IP. In such cases, if the “Strictly Enforce Location Policy” option is disabled, Entra ID understands this as a legitimate request and issues a new token without CAPID. This allows the client to access resources without location-based restrictions. Thank you for time to go through my blog. Do share your feedbacks.
