SAML

Security Assertion Markup Language (SAML) 2.0 is an XML-based standard for federated single sign-on between identity providers and applications. In a SAML SSO flow, the app redirects the user to the identity provider (Entra ID); the IdP authenticates and returns a signed XML assertion with claims about the user; the app validates the signature and creates a session. Each application has its own Entity ID, Reply URL (ACS URL), claim mappings, and signing certificate. Microsoft Entra ID supports SAML for thousands of SaaS apps via the enterprise applications gallery. SAML is mature and ubiquitous in legacy enterprise SaaS; modern apps increasingly prefer OpenID Connect (OIDC), but SAML remains widely used.

SP-initiated vs IdP-initiated

There are two ways a SAML sign-in can start. SP-initiated is the normal case: the user goes to the application first, the application (the "service provider") redirects them to Entra ID with a SAML request naming which app it's for, and the flow completes back at the app's Reply URL. IdP-initiated skips that first redirect: the user starts from a tile in the Entra ID My Apps portal, and Entra ID sends the assertion straight to the app without ever having received a request from it. IdP-initiated is convenient but a well-known source of security findings, because the app has no way to correlate the assertion with a request it made — some SAML apps reject IdP-initiated sign-in outright for exactly that reason, and it's worth checking before assuming both paths work for a newly onboarded app.

Worked example

A finance team needs SSO into a SaaS expense-reporting tool that only supports SAML. An admin adds it from the enterprise applications gallery (or as a non-gallery app if it isn't listed), then configures three things on the Entra ID side: the Entity ID and Reply URL supplied by the vendor's own admin portal, and which user attributes map to which SAML claims (typically email address as the Name ID, plus a department or role claim the app uses to set permissions internally). Entra ID generates a signing certificate and federation metadata XML; the vendor imports that metadata on their end. From that point, a user clicking the app tile in My Apps is redirected, authenticated silently if they already have an Entra ID session, and signed into the expense tool with no separate password ever created for it.

Where SAML fits next to Conditional Access

SAML sign-ins go through the same Entra ID authentication pipeline as everything else, so Conditional Access, MFA, and sign-in risk evaluation all apply before the assertion is ever issued — SAML isn't a side door around modern security controls, it's a different token format for the same evaluated sign-in. The one thing to watch is claim mapping: if the app relies on a claim (like department) to authorise what the user can do internally, a misconfigured or stale attribute in Entra ID silently breaks that app's authorisation, not its authentication — the user signs in fine and then can't see the data they expect.

Common pitfalls

Certificate expiry is the single most common SAML outage: the signing certificate Entra ID issues has an expiry date, and if nobody renews it before then, every SSO sign-in to that app fails at once, usually discovered by a flood of user complaints rather than a proactive alert. The second common issue is a Reply URL mismatch after a vendor migrates their platform to a new domain — the old URL keeps working right up until the vendor's DNS or hosting changes, then breaks without warning unless the admin updated it on both sides. The third is assuming SAML claim mapping is retroactive: changing which attribute feeds a claim doesn't touch users already signed in with a cached session.