Skip to main content
Identity Authority
Category: Federation & SSO

Security Assertion Markup Language

Also known as: SAML, SAML 2.0
Simply put

SAML is a standardized, XML-based way for a trusted identity system to tell an external application that a user has signed in and is who they claim to be. It lets people use one login to access multiple applications, so those applications do not each have to verify the user's credentials directly. SAML is most commonly used to enable web-based single sign-on between organizations and their service providers.

Formal definition

SAML is an XML-based framework, standardized by OASIS (SAML 2.0 being the widely deployed version), for exchanging security information between an identity provider (IdP) and a service provider (SP). Its central artifact is the SAML assertion, an XML document conveying statements, typically authentication, attribute, and authorization decision statements, that an SP relies on to make access-control decisions. In a typical web SSO deployment, the IdP authenticates the principal and issues a signed assertion asserting that authentication occurred; the SP validates the assertion and establishes a security context for the user. Assertions are typically digitally signed to ensure integrity and authenticity, though signing is distinct from encryption, and message confidentiality depends on the profile and transport used. The precise bindings, profiles, and trust configuration vary by deployment; SAML addresses federated authentication and assertion exchange, while fine-grained runtime authorization and identity lifecycle management are generally handled by other mechanisms.

Why it matters

SAML solved a foundational problem in federated identity: allowing users to authenticate once with a trusted identity provider (IdP) and then access multiple external service providers (SPs) without each application independently verifying credentials. This reduces credential sprawl, centralizes authentication policy, and gives organizations a single point at which to enforce and audit sign-in. For enterprises integrating with SaaS applications and cross-organizational partners, SAML 2.0 remains one of the most widely deployed web SSO standards, and much existing enterprise infrastructure depends on it.

Because SPs make access-control decisions based on the statements in a SAML assertion, the integrity and authenticity of that assertion are critical. SAML assertions are typically digitally signed so that an SP can trust that the assertion genuinely originated from the expected IdP and was not altered in transit. Misconfigurations, such as failing to validate signatures correctly, accepting improperly scoped assertions, or mishandling trust configuration, can undermine the security guarantees the standard is meant to provide. It is also important to remember that signing establishes integrity and authenticity, not confidentiality; message confidentiality depends on the profile and transport in use.

Understanding SAML's scope helps teams avoid overextending it. SAML addresses federated authentication and the exchange of assertions between an IdP and an SP. It does not, on its own, deliver fine-grained runtime authorization or identity lifecycle management, which are generally handled by other mechanisms. Treating SAML as a complete access-control solution rather than as a federated authentication and assertion-exchange framework can lead to gaps in governance and enforcement.

Who it's relevant to

Security Architects
Architects designing federation between an organization and its service providers use SAML 2.0 to establish trust relationships and centralize web SSO. They must decide how assertions are signed, which bindings and profiles to use, and how transport-level confidentiality is provided, while recognizing that SAML handles federated authentication and assertion exchange rather than fine-grained runtime authorization.
IAM Engineers
Engineers implementing and integrating SAML connections configure IdP-to-SP trust, assertion signing, and validation logic. Correctly validating signatures, scoping, and trust configuration is essential, since SPs make access-control decisions based on the statements in the assertion, and misconfiguration can undermine the security the standard provides.
Compliance and Audit Leads
Because SAML centralizes authentication at the IdP, it offers a single point to enforce and audit sign-in across federated applications. Compliance officers should note, however, that SAML does not by itself provide identity lifecycle management or fine-grained authorization, so certification, access reviews, and governance controls must be addressed through other mechanisms.
System Administrators
Administrators operating SAML-based SSO manage IdP and SP settings, certificates used for assertion signing, and trust configuration. Understanding that a signed assertion provides integrity and authenticity but not confidentiality helps them ensure that transport and profile choices adequately protect assertions in transit.

Inside SAML

SAML Assertion
An XML document issued by the identity provider that conveys statements about a subject. Assertions typically carry authentication statements (how and when the subject authenticated), attribute statements (subject attributes such as email or group membership), and authorization decision statements, though the latter are rarely used in practice.
Identity Provider (IdP)
The party that authenticates the principal and issues SAML assertions. The IdP performs identification and authentication of the user; the actual authorization decision generally remains with the relying party based on the asserted attributes.
Service Provider (SP)
The relying party that consumes assertions to establish a web SSO session. In most deployments the SP maps asserted attributes to local authorization decisions, keeping authentication (handled via the assertion) distinct from authorization (enforced by the SP).
Bindings
The transport mechanisms that define how SAML messages are conveyed, such as HTTP-Redirect, HTTP-POST, and SOAP-based Artifact bindings. The choice of binding affects how requests and responses move between IdP and SP.
Profiles
Combinations of assertions, protocols, and bindings that address specific use cases. The Web Browser SSO profile is the most common; other profiles cover scenarios such as single logout, depending on deployment.
Metadata
XML documents describing an entity's configuration, including entity identifiers, endpoint URLs, supported bindings, and signing/encryption certificates. Metadata is used to establish trust and interoperability between IdP and SP.
Signing and Encryption
SAML supports XML digital signatures to protect assertion integrity and authenticity, and XML encryption to protect confidentiality. Signing establishes that an assertion was not tampered with and originates from the expected issuer; it is distinct from encryption, which conceals the contents.

Common questions

Answers to the questions practitioners most commonly ask about SAML.

Does SAML handle authorization as well as authentication?
Not directly. SAML is primarily a federation standard for web SSO that lets an identity provider (IdP) assert authentication and identity information to a service provider (SP). While a SAML assertion can carry attributes (via the AttributeStatement) that an SP may use as inputs to its own authorization decisions, SAML itself does not define an authorization model such as RBAC or ABAC, nor does it act as a policy decision point (PDP) or policy enforcement point (PEP). The identification and authentication steps are performed at the IdP; the authorization step remains the responsibility of the SP or a separate access control layer. Note that the older SAML profiles for authorization decision statements exist in the specification but are rarely used in typical web SSO deployments.
Is SAML outdated now that OAuth 2.0 and OpenID Connect exist?
Not necessarily, and framing it that way conflates different scopes. SAML 2.0 is an XML-based federation standard for web SSO, OAuth 2.0 is a delegated authorization framework, and OpenID Connect is an authentication layer built on top of OAuth 2.0. Because their purposes differ, they are not straightforward replacements for one another. SAML remains widely deployed for enterprise web SSO, particularly with established SPs and IdPs that already support it. OIDC is often preferred for newer applications, native mobile apps, and API-centric architectures where JSON and OAuth 2.0 flows fit better. In most enterprises the two coexist, and the appropriate choice depends on the applications, existing infrastructure, and integration requirements rather than one standard being universally superior.
What is the difference between SP-initiated and IdP-initiated SSO in SAML?
In SP-initiated SSO, the flow begins when the user attempts to access the service provider, which then generates an authentication request (typically an <AuthnRequest>) and redirects the user to the identity provider. In IdP-initiated SSO, the flow begins at the identity provider, which generates an unsolicited assertion and posts it to the service provider, often from a portal or application launcher. SP-initiated flows are generally considered more robust because the SP supplies request context and can better correlate the response; IdP-initiated flows lack a corresponding request and can be more susceptible to certain replay or misrouting concerns depending on configuration. Support for each depends on the specific SP and IdP implementations.
How is a SAML assertion secured in transit and at rest?
SAML assertions are typically protected using XML Signature to ensure integrity and authenticity, so a relying party can verify that the assertion originated from the trusted IdP and was not altered. Signing, however, is not the same as encryption: a signed assertion is still readable unless XML Encryption is additionally applied to the assertion or specific elements, which some deployments use to protect sensitive attributes. Transport-level protection via TLS is also standard for the browser-facing redirects and POST bindings. The exact combination of signing, encryption, and TLS depends on the profile, binding, and the configuration agreed between the SP and IdP.
What role does SAML metadata play in establishing trust between an IdP and SP?
SAML metadata is an XML document that describes each party's configuration, typically including entity identifiers, endpoint URLs for the relevant bindings, supported name identifier formats, and the signing and encryption certificates used to validate or protect assertions. Exchanging and correctly loading metadata is how an SP and IdP establish the trust relationship and key material needed to verify signatures and route messages. In most deployments, keeping certificates current in the metadata is essential, since expired or rotated keys are a common cause of federation failures. Some environments consume metadata from a published URL to ease rotation, though the supported mechanisms depend on the products involved.
How does user provisioning relate to SAML-based SSO?
SAML addresses runtime authentication and SSO, not account lifecycle management, so provisioning is generally handled separately. An SP typically needs a user account or record to exist before or at the time of a SAML login. Some deployments use just-in-time (JIT) provisioning, creating or updating the local account from attributes in the assertion at first login, while others provision and deprovision accounts out of band using a dedicated protocol such as SCIM. Distinguishing these concerns matters for governance: identity governance and administration functions like access reviews, certification, and deprovisioning are not performed by SAML itself, and relying solely on JIT provisioning can leave stale accounts if deprovisioning is not addressed by a separate process.

Common misconceptions

SAML and OAuth 2.0 are interchangeable and solve the same problem.
SAML 2.0 is an XML-based federation standard primarily for web SSO that conveys authentication and attribute statements, whereas OAuth 2.0 is a delegated authorization framework and is not an authentication protocol. They address different concerns and are frequently used in different contexts.
A signed SAML assertion is also confidential because it is protected by cryptography.
Signing provides integrity and authenticity, not confidentiality. Unless XML encryption is applied, the contents of a signed assertion can still be read by anyone who intercepts it. Signing and encryption are separate protections.
SAML handles both authentication and authorization for the service provider.
SAML primarily conveys that a subject was authenticated and carries attributes about that subject. While the specification defines authorization decision statements, they are seldom used; in most deployments the service provider makes its own authorization decisions based on the asserted attributes.

Best practices

Validate assertion signatures against trusted metadata and reject unsigned or improperly signed assertions to ensure integrity and authenticity.
Enforce assertion conditions such as NotBefore/NotOnOrAfter time windows, audience restrictions, and one-time-use where applicable to reduce replay risk.
Apply XML encryption to assertions or specific attributes when confidentiality is required, recognizing that signing alone does not conceal contents.
Exchange and periodically refresh metadata through a trusted process, and manage certificate rotation carefully to avoid trust failures.
Keep authentication and authorization concerns separate by treating asserted attributes as input to the service provider's own authorization decisions rather than as authorization grants.
Prefer POST-based bindings with signed responses over less protected options where the deployment and standard profile allow, and constrain endpoints to expected values.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps