Skip to main content

SAML v2.0 SSO with Entra ID - Integration Guide

Field

Details

Document Type

How-To Guide: SSO Integration

Applies To

Microsoft Entra ID, Any SAML 2.0-compatible SaaS or Third-Party Application

Audience

2nd Line / Systems Administrator / IT Engineer

Author

AK. Udofeh

Last Updated

March 2026

Overview

This article covers how to configure Single Sign-On (SSO) using the SAML 2.0 protocol between Microsoft Entra ID and any third-party or SaaS application that supports SAML for authentication. It is intended for systems administrators who need to integrate enterprise applications with Entra ID to centralise identity management, enforce MFA, and control user access. The guide covers Enterprise Application creation in Entra ID, SAML endpoint configuration, certificate handling, and attribute claim mapping.

 

SAML SSO works by delegating authentication to Entra ID as the Identity Provider (IdP). The application (Service Provider / SP) redirects the user to Entra's SAML endpoint, which authenticates the user and returns a signed SAML assertion containing identity attributes. The application validates the assertion signature using Entra's signing certificate and establishes a user session.

Common Failure Points

    • Incorrect ACS (Assertion Consumer Service) URL registered in Entra
    • Entity ID mismatch between the application and Entra configuration
    • Entra signing certificate not imported into the application, or certificate has expired
    • Attribute claims not mapping to the fields the application expects
    • SLO (Single Logout) URL misconfigured, causing logout failures
    • User not assigned to the Enterprise Application in Entra

Before You Start

Check

Where

You have Global Administrator or Application Administrator rights in Entra ID

Entra ID > Roles and Administrators

The target application supports SAML 2.0 (not only OIDC)

Application vendor documentation

You have the application's ACS URL, Entity ID, and SLO URL

Application vendor documentation or SP metadata XML

Outbound HTTPS (port 443) from the application server to login.microsoftonline.com is permitted

Firewall / network policy

You have admin access to the application's configuration

Application admin console or hosting environment

Step 1:  Create an Enterprise Application in Entra ID

For SAML SSO, configuration is done through Enterprise Applications, not App Registrations. An App Registration is created automatically in the background.

    • Navigate to portal.azure.com > Entra ID > Enterprise Applications > New application.
    • Click Create your own application.
    • Enter a display name (e.g. AppName SAML SSO).
    • Select "Integrate any other application you don't find in the gallery".
    • Click Create.

You will be taken to the application overview page.

 

Step 2:  Configure SAML Settings

If the application provides a metadata XML URL (e.g. https://app.yourdomain.com/saml/metadata), Entra can import these values automatically — click Upload metadata file at the top of the Basic SAML Configuration panel.

Click Save.

 

Step 3:  Download the Entra Signing Certificate

    • Still in the SAML configuration view, scroll to Section 3 > SAML Certificates.
    • Download Certificate (Base64) > this produces a .cer or .pem file.
    • Open the file in a text editor. The content between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- is the base64-encoded certificate value you will need for the application.

Store a copy of this certificate securely. If Entra's signing certificate is rotated (e.g. on expiry), the application will fail to validate assertions until the new certificate is imported.

Step 4: Collect IdP Configuration Values

In the SAML configuration page, note the following values in the "Set up <app name>":

Value

Description

Login URL

Entra's SAML SSO endpoint - set as the IdP SSO URL in the application

Logout URL

Entra's SAML SLO endpoint - set as the IdP SLO URL in the application

Entra ID Identifier

Entra's Entity ID - set as the IdP Entity ID in the application

Certificate (Base64)

Signing certificate from Step 3 - used by the application to validate assertions

Alternatively, download the Federation Metadata XML from the same section - many applications can import this file directly to auto-populate all IdP settings.

Step 5: Configure Attribute Claims in Entra

By default, Entra sends a standard set of SAML attribute claims. Verify these match what the application expects:

    • In the Enterprise Application SAML configuration, click Edit on Section 2 - Attributes & Claims.

            The default claims sent by Entra are:

Claim Name

Value

emailaddress

user.mail

givenname

user.givenname

surname

user.surname

name

user.userprincipalname
  • If the application requires different attribute names or additional claims, click Add new claim to add or rename them.
  • To include group membership in the assertion (for role mapping), click Add a group claim > select Security groups.

By default, Entra sends group Object IDs (GUIDs) in the group claim, not display names. Configure the application's role mapping to use Object IDs, or change the group claim's source attribute to display names if supported.

Step 6: Restrict Access via Enterprise Application (Recommended)

    • In the Enterprise Application, go to Properties.
    • Set "Assignment required?" to Yes > Save.
    • Go to Users and groups > Add user/group > assign the relevant users or Entra security groups.

      Only assigned users will be permitted to authenticate via SAML SSO. Unassigned users receive an Entra-side access denied error before reaching the application.

Step 7: Configure the Application

In the Service Provider application, enter the values collected in Step 4 into the application's SAML configuration. The exact setting names vary per application - refer to the application vendor's SAML documentation. The standard SAML parameters are:

Application Setting

Value to Enter

IdP Entity ID

Entra ID Identifier from Step 4

IdP SSO URL

Login URL from Step 4

IdP SLO URL

Logout URL from Step 4

IdP X.509 Certificate

Certificate base64 content from Step 3

SP Entity ID

Must match the Identifier (Entity ID) entered in Entra Step 2

ACS URL

Must match the Reply URL entered in Entra Step 2

Name ID Format

emailAddress or persistent - check application documentation

Binding

HTTP-POST for ACS; HTTP-Redirect for AuthnRequest

=========================Troubleshooting====================

AADSTS750054: SAMLRequest or SAMLResponse must be present as query string parameters

Cause: The application is not correctly forming the SAML AuthnRequest, or the binding type does not match Entra's expectation.

Resolution:

    • Confirm the application is using HTTP Redirect binding for the AuthnRequest - Entra requires this for SP-initiated flows.
    • Check the application's SAML configuration for a "request binding" or "binding type" setting and ensure it is set to HTTP-Redirect.

AADSTS70011: The provided value for the input parameter 'redirect_uri' is not valid

Cause: The ACS URL registered in Entra does not match the URL the application is posting to.

Resolution:

    • Retrieve the application's SP metadata from its metadata URL or admin panel.
    • Compare the AssertionConsumerService URL in the metadata against the Reply URL (ACS URL) registered in Entra.
    • Update the Reply URL in Entra to match exactly - including scheme (https://), full path, and no trailing slash.

AADSTS750057: Invalid SAML response or no SAML response

Cause: The Entity ID in the application does not match what is registered in Entra, or the SAML response is malformed.

Resolution:

    • Confirm the SP Entity ID configured in the application exactly matches the Identifier (Entity ID) in Entra.
    • Confirm the IdP Entity ID configured in the application matches the Entra ID Identifier shown in Section 4 of the Entra SAML page.
    • These values are case-sensitive and must match character for character.

Assertion signature validation fails / Invalid signature

Cause: The X.509 certificate used for validation in the application does not match the current Entra signing certificate, or the certificate has expired.

Resolution:

    • In the Enterprise Application SAML configuration > Certificates > check the expiry date of the active certificate.
    • If expired or rotated, click New Certificate, make it active, and download the new Base64 certificate.
    • Import the new certificate into the application's SAML configuration.
    • Restart the application service if required.

Entra signing certificates expire every 3 years by default. Set a calendar reminder 60 days before expiry to plan a rotation window.

 

Single Logout (SLO) does not work - user remains signed in to Entra after signing out of the application

Cause: The SLO URL is not configured in either Entra or the application, or the binding types do not match.

Resolution:

    • Confirm the Logout URL field in Entra's Basic SAML Configuration points to the application's SLO endpoint.
    • Confirm the application's IdP SLO URL is set to the Logout URL shown in Entra Section 4.
    • Entra uses HTTP Redirect binding for logout requests - confirm the application's SLO endpoint accepts GET/Redirect binding, not only POST.

User authenticates successfully in Entra but receives an error or no access in the application

Cause: The SAML assertion was accepted, but the user account was provisioned with no role or permissions in the application.

Resolution:

    • Log in to the application as an administrator.
    • Assign an appropriate role to the SSO-provisioned user account.
    • To automate this for future users, configure a default role for SSO-registered accounts, or implement group-to-role mapping using the group claim configured in Step 6.

Attribute claims are empty or not recognised by the application

Cause: The attribute claim names sent by Entra do not match the names the application is expecting.

Resolution:

    • In Entra → Enterprise Application > Attributes & Claims, note the full claim URI names being sent (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress).
    • Cross-reference these with the application's expected attribute names from the vendor documentation.
    • Either rename claims in Entra to match the application, or update the application's attribute mapping to match Entra's output.
    • Use a SAML tracer browser extension or the application's debug mode to inspect the raw assertion during a test login.

Expected Outcome

Factor

Detail

Resolution Time

45–90 minutes for initial configuration; additional time if attribute mapping requires investigation

User Impact

Zero - SAML SSO is additive; existing local accounts remain functional during migration

Recurrence Risk

Low - primary recurring issue is Entra signing certificate expiry (every 3 years by default)

Ongoing Maintenance

Rotate Entra signing certificate before expiry; manage user access via Enterprise Application assignments

No comments to display

Back to top