SAML 2.0 in Depth

SAML federation: identity authenticated in one domain and consumed in another

Central principle

SAML transports security assertions between entities that have already established metadata , keys, and trust rules.

In-depth edition - study material and professional reference

radio_button_unchecked Chapter presentation

Previous chapters studied OAuth 2.0, OpenID Connect, and the JOSE family. These standards dominate modern applications and APIs, but they have not completely replaced the enterprise federation mechanisms built before them. SAML 2.0 remains widely present in corporate portals, SaaS systems, academic environments, governments, banks, and cross-organization integrations that require browser-based Single Sign-On and standardized attribute exchange.

SAML, short for Security Assertion Markup Language, is an XML framework for communicating authentication assertions, attributes, and authorization decisions. Its best-known use is the Web Browser SSO Profile , in which an Identity Provider authenticates the user and sends a signed SAML Assertion to the Service Provider. However, understanding the visual flow of redirection alone is insufficient. Security depends on bindings, metadata , certificates, XML signature validation, temporal conditions, audience, recipient, correlation and replay protection.

Unlike a simple bearer token transported directly to an API, the SAML response is typically consumed by a specific Service Provider endpoint called an Assertion Consumer Service. The SP validates the message and creates its own local session. This separation explains why SAML is especially suited to federated login for web applications, but less natural for delegated authorization of APIs and service-to-service calls.

This chapter builds a complete mental model of SAML 2.0: actors, assertions, protocol messages, bindings, profiles, metadata , NameID , attributes, signature, encryption, Single Logout, federation and integration with gateways. The focus is to enable secure design, review and troubleshooting, without reducing the standard to copying certificates between two administrative consoles.

How to study this chapter

Always separate four layers: assertion , protocol message, binding and profile . Then, follow the trust relationship described in metadata and validate each security restriction. This decomposition makes SAML much less confusing and avoids mixing transport, identity and session.

Learning Objectives

• Explain the responsibilities of principal, Identity Provider, Service Provider, and SAML authorities.
• Distinguish assertion , protocol message, binding , profile and metadata .
• Describe authentication statements, attributes and authorization decisions.
• Detail the Web Browser SSO Profile in SP -initiated and IdP -initiated modes.
• Interpret AuthnRequest , Response, Assertion , Subject, Conditions and SubjectConfirmation .
• Compare HTTP-Redirect, HTTP-POST, HTTP-Artifact and SOAP bindings.
• Understand entityID , ACS , SSO Service, SLO Service, KeyDescriptor and certificate rotation.
• Apply secure XML Signature validation and recognize signature wrapping and replay.
• Understand NameID , attributes, identity mapping, SLO and IdP discovery.
• Compare SAML 2.0 with OpenID Connect and recognize the role of identity gateways and brokers.

Chapter structure

• 19.1 SAML 2.0 Fundamentals and Components
• 19.2 Assertions and statements
• 19.3 Protocol messages
• 19.4 Web Browser SSO Profile
• 19.5 SP -initiated and IdP -initiated SSO
• 19.6 AuthnRequest in depth
• 19.7 Response and Assertion in depth
• 19.8 Conditions, SubjectConfirmation and correlation
• 19.9 SAML Bindings
• 19.10 Metadata and trust
• 19.11 XML Signature and encryption
• 19.12 NameID , attributes and mapping
• 19.13 Sessions, SLO and discovery
• 19.14 SAML x OIDC, gateways, security and troubleshooting
• Summary, checklist, exercises, glossary and references

radio_button_unchecked 19.1 SAML 2.0 Fundamentals and Components

SAML organizes the federation into entities with well-defined roles. The principal is normally the user. The Identity Provider, or IdP , authenticates this principal and issues claims. The Service Provider, or SP , offers the application and trusts the assertions produced by the IdP according to a previously configured relationship. In broader scenarios, there may also be Attribute Authorities, Authentication Authorities and Policy Decision Points.

The pattern is made up of complementary pieces. Core defines assertions and protocol messages. Bindings describe how these messages are transported over protocols such as HTTP or SOAP. Profiles combine assertions, messages and bindings to solve concrete use cases, such as browser SSO or Single Logout. Metadata describes entities, endpoints, supported bindings, identifiers, certificates, and other information necessary for interoperability.

The trust relationship does not arise because a message contains a certificate. The SP must know in advance the entityID of the IdP and the keys accepted for signing. Likewise, the IdP needs to know the entityID of the SP , its ACS endpoints and, depending on the policy, the keys used by the SP . Metadata is the standard mechanism for distributing this information, but obtaining and updating it also needs to be authenticated and governed.

radio_button_unchecked 19.2 Assertions and statements

A SAML Assertion is an XML structure issued by an authority and related to a subject. It has identifier, version, issue time, issuer and zero or more statements. It may also contain a signature, conditions and information on how the subject must confirm its identity to the recipient.

The Authentication Statement records that an authority authenticated the subject at a given time and context. It can include SessionIndex, SessionNotOnOrAfter and AuthnContextClassRef, elements used by applications that need to distinguish password, MFA, certificate or other methods. The Attribute Statement carries name and value pairs, such as internal identifier, email, organizational unit, or groups.

The Authorization Decision Statement represents an authorization decision about a resource, but is less common in modern Web SSO. In practice, many SPs use authentication attributes and context to power their own local policies. This choice preserves domain autonomy, but requires clear agreements on semantics, cardinality, namespaces, and handling of missing attributes.

radio_button_unchecked 19.3 Protocol messages

SAML protocol messages coordinate interactions between entities. AuthnRequest asks for authentication; Response carries one or more assertions or an error status; LogoutRequest and LogoutResponse participate in Single Logout; ArtifactResolve and ArtifactResponse retrieve messages by reference; AttributeQuery and AuthnQuery query specialized authorities.

Each message has ID, Version, IssueInstant and, depending on the type, Destination, Consent, InResponseTo and other attributes. These fields are not decorative. The ID allows for correlation and replay protection. Destination restricts the expected endpoint. InResponseTo links a response to a previously issued request. IssueInstant assists with temporal validation and investigation of misaligned clocks.

The Response status needs to be interpreted before the assertion . Success indicates that the main processing is complete, but does not override all validations. Other codes may represent requester error, reply error, authentication failed, unsupported method, unknown user, or lack of consent.

Exemplo simplificado de AuthnRequest
<samlp:AuthnRequest
  ID="_a12f..."
  Version="2.0"
  IssueInstant="2026-07-15T18:20:00Z"
  Destination="https://idp.empresa.example/sso"
  AssertionConsumerServiceURL="https://app.example/saml/acs">
  <saml:Issuer>https://app.example/saml</saml:Issuer>
  <samlp:NameIDPolicy AllowCreate="true"/>
</samlp:AuthnRequest>

radio_button_unchecked 19.4 Web Browser SSO Profile

The Web Browser SSO Profile is the most well-known use of SAML 2.0. The browser acts as an intermediary between SP and IdP . When the user accesses a protected resource, the SP creates an AuthnRequest and redirects or sends the browser to the IdP . The IdP authenticates the user, creates the Response, signs the assertion or the response itself according to the agreement and returns the result to the SP 's Assertion Consumer Service.

The ACS receives the message, performs structural, cryptographic and semantic validations and, if everything is correct, creates a local application session. SAML does not define how this local session should be implemented. It may use a secure cookie, server-side session or other mechanism. This means that post-login security also depends on classic controls such as Secure, HttpOnly, SameSite, expiration, rotation and fixation protection.

RelayState preserves application state, such as the resource originally requested. It should not be treated as a trusted authorization channel and needs to be protected against open redirect and tampering. The implementation must only accept predicted targets or opaque values stored server-side.

radio_button_unchecked 19.5 SP -initiated and IdP -initiated SSO

In SP -initiated SSO, the flow starts at the Service Provider. The SP creates an AuthnRequest , registers its ID, and expects a correlated response. This model allows better control of context, destination and return to the requested resource. InResponseTo validation mitigates cold-response attacks and helps associate authentication with the correct transaction.

In IdP -initiated SSO, the flow starts in an IdP portal or application catalog. The IdP sends an unsolicited Response to the SP 's ACS . This mode is convenient for corporate portals, but it loses correlation with an AuthnRequest . The implementation needs to compensate for this reduction in context with strict controls on issuer, audience, recipient, time, replay and allowed destinations.

Some applications support both modes. In this situation, the validation code must clearly distinguish between requested and unsolicited responses. It's not safe to simply make InResponseTo optional in all cases. The policy needs to define when IdP -initiated is accepted, for which IdPs, ACSs and business flows.

Table 3 - The two modes require different validation policies.

radio_button_unchecked 19.6 AuthnRequest in depth

The AuthnRequest communicates to the IdP which SP requests authentication and, optionally, which characteristics it wants. Issuer identifies the SP . Destination points to the IdP endpoint. AssertionConsumerServiceURL or AssertionConsumerServiceIndex selects the ACS . ProtocolBinding can indicate how the Response should return. NameIDPolicy requires identifier format and may allow creation of a new pseudonym.

ForceAuthn requests the IdP to reauthenticate the user even if an SSO session exists. IsPassive asks that the IdP not interact with the user; If silent authentication cannot be performed, the response should indicate appropriate failure. RequestedAuthnContext expresses requirements about authentication method or strength, but its interpretation needs to be aligned between the parties.

Signing AuthnRequest may be required by policy, especially when the SP sends dynamic ACS , requests ForceAuthn, or operates in federations with strong requirements. In Redirect binding , the signature occurs over URL parameters and not over a ds:Signature element within the XML. In POST binding , the message can carry XML Signature. Confusing these two forms is a common cause of failure.

radio_button_unchecked 19.7 Response and Assertion in depth

The Response is the protocol message delivered to the SP . It has Issuer, Status, Destination, InResponseTo and can contain assertions. In many profiles, Response and Assertion can be signed in different combinations. The SP policy must define exactly which signature is required and on which element, avoiding inconsistently accepting partially protected messages.

The Assertion contains the statements consumed by the application. The SP must find the assertion authenticated by a validated signature, and not simply the first assertion with a given XPath. This rule is central against XML Signature Wrapping , an attack in which a valid signed element is moved and another malicious element is placed in the location that the application processes.

A full validation also checks Issuer, Version, IssueInstant, Conditions, AudienceRestriction, SubjectConfirmationData, Recipient, NotOnOrAfter, InResponseTo , AuthnStatement, and required context. After validation, attributes must be mapped by explicit rules. The fact that an XML has been signed does not make all values suitable for the application.

Estrutura simplificada de Response e Assertion
<samlp:Response Destination="https://app.example/saml/acs"
                    InResponseTo="_a12f...">
  <saml:Issuer>https://idp.example/metadata</saml:Issuer>
  <samlp:Status>...</samlp:Status>
  <saml:Assertion ID="_assertion123">
    <saml:Subject>...</saml:Subject>
    <saml:Conditions>...</saml:Conditions>
    <saml:AuthnStatement>...</saml:AuthnStatement>
    <saml:AttributeStatement>...</saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

radio_button_unchecked 19.8 Conditions, SubjectConfirmation and correlation

Conditions restrict when and where the assertion can be used. NotBefore defines the starting instant, and NotOnOrAfter defines a unique limit. AudienceRestriction indicates the entities for which the assertion was issued. The application must compare the audience with its expected identifier and use small and controlled clock tolerance, without transforming clock skew into a wide replay window.

SubjectConfirmation typically uses the bearer method in Web Browser SSO. SubjectConfirmationData carries Recipient, NotOnOrAfter and InResponseTo . Recipient needs to match the ACS actually used. InResponseTo must point to a pending AuthnRequest when the flow was initiated by the SP . An already processed response must be marked as consumed to prevent replay.

Correlation also involves RelayState , temporary cookies, and local state. These elements do not replace each other. InResponseTo relates the Response to the AuthnRequest ; RelayState returns application context; the SP temporary session stores information about the transaction. A robust design maintains all links and removes the state after use.

radio_button_unchecked 19.9 SAML Bindings

Binding defines how a SAML message is mapped to another protocol. In HTTP-Redirect binding , the message is normally compressed with DEFLATE, encoded in Base64 and placed in the query string. It's suitable for small AuthnRequests, but has URL limits and specific signature rules around SAMLRequest, RelayState , and SigAlg.

In HTTP-POST binding , the Base64 message is sent in an HTML form, usually by auto-submit. It is the most common binding to transport SAMLResponse to ACS . As the browser delivers content from one domain to another, the endpoint needs to accept POST, protect local session and fully validate the message before any redirection.

HTTP-Artifact only sends a short reference via the browser. The SP exchanges the artifact for the actual message in a back-channel, typically with SOAP. This reduces assertion exposure to the user agent, but adds availability, authentication and latency to the artifact resolution service. SOAP also appears in back-channel queries and Single Logout.

radio_button_unchecked 19.10 Metadata and trust

SAML Metadata describes entities through EntityDescriptor. An entityID is a stable identifier, often a URI, but does not need to be an accessible URL. Role descriptors inform whether the entity acts as an IdP , SP or other authority. Endpoints include binding , location, index, and preference. KeyDescriptor publishes certificates associated with signing or encryption.

SP metadata usually contains ACS endpoints, NameID formats and certificates. IdP metadata contains SingleSignOnService, SingleLogoutService, certificates, and other resources. The consumer must only accept endpoints and keys from trusted sources. Allowing arbitrary ACS coming only from AuthnRequest can turn the IdP into a transmitter of assertions for an attacker.

Certificate rotation requires overlap. The new certificate must be published before it can be used; the old one remains while messages and caches can still depend on it. Expired certificate in metadata should not be treated simplistically: the use of X.509 in SAML is often as a key container, but corporate policies may require additional validations. The important thing is to have explicit and auditable rules.

Exemplo simplificado de metadata de SP
<md:EntityDescriptor entityID="https://app.example/saml">
  <md:SPSSODescriptor AuthnRequestsSigned="true"
      protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">...</md:KeyDescriptor>
    <md:AssertionConsumerService
       Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
       Location="https://app.example/saml/acs"
       index="0" isDefault="true"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

radio_button_unchecked 19.11 XML Signature and encryption

XML Signature protects the integrity and authenticity of XML elements. It references an element by ID, applies transforms, canonicalization and digest and produces SignatureValue. Canonicalization exists because semantically equivalent XML can have differences in whitespace, namespaces, and attribute ordering. The implementation must use mature libraries and a strict policy on algorithms, transforms and references.

The XML Signature Wrapping attack exploits divergence between the verified element and the consumed element. The core defense is to resolve the signed reference securely, require unique IDs, reject unexpected structures, and process exactly the authenticated node. Generic XPath queries like looking for the first Assertion in the document are dangerous when they are not tied to cryptographic verification.

XML Encryption allows you to encrypt the Assertion , the NameID or attributes. The IdP uses the SP 's public encryption key, and the SP decrypts with its private key. Signing and encryption solve different problems: encryption protects confidentiality along the way and at intermediaries; signature protects integrity and origin. Even an encrypted assertion needs to be validated after decryption.

Implementation Rule

Never implement XML Signature manually with string concatenation or improvised XPath. Use specialized library, maintain hardened XML parser, disable external entities and validate structure, IDs and references before consuming attributes.

radio_button_unchecked 19.12 NameID , attributes and identity mapping

NameID identifies the subject in standardized formats. Persistent produces a stable and generally opaque identifier. Transient creates a temporary value. EmailAddress uses email, but may be unsuitable as an immutable key. Unspecified depends on bilateral agreement. The choice must consider privacy, correlation between SPs, data changes and account lifecycle.

Attributes are identified by Name and, optionally, NameFormat and FriendlyName. The SP should not rely solely on informal names such as role or group without a contract. It is necessary to define namespace, type, cardinality, authoritative origin and meaning. A directory group may not equate to a business permission, and automatic mappings may inappropriately elevate privileges.

Account linking deserves care. When the SP receives a federated subject, it needs to link it to a local account. Linking via email only may allow takeover if different providers issue the same address or if email verification is not equivalent. The recommended key typically combines issuer and stable subject identifier, with controlled processes for migration.

radio_button_unchecked 19.13 Sessions, Single Logout and discovery

There are at least two distinct sessions: the user session on the IdP and the local session on the SP . The AuthnStatement can contain SessionIndex and SessionNotOnOrAfter, but the SP decides how to create and expire its cookie. Terminating the IdP session does not automatically terminate all local sessions unless Single Logout is supported and works across the chain.

Single Logout coordinates LogoutRequest and LogoutResponse between participants. You can use front-channel through the browser or back-channel. In practice, partial failures are common: an unavailable SP , blocked cookie or timeout can leave sessions active. Therefore, SLO should not be treated as a substitute for short sessions, local revocation and own risk controls.

IdP Discovery appears when an SP accepts multiple providers. The choice can be made by user domain, portal, discovery cookie or dedicated service. The interface should avoid phishing and confusing selection. In broad federations, aggregated metadata and discovery services need to be operated with signature, expiration, filters and governance.

radio_button_unchecked 19.14 SAML 2.0 x OpenID Connect

SAML 2.0 and OpenID Connect resolve federated authentication, but they have different models and ecosystems. SAML uses XML, assertions, bindings and browser profiles. OIDC uses OAuth 2.0, JSON, JWT, HTTP and Discovery/JWKS endpoints. OIDC tends to fit better into mobile applications, SPAs, APIs and modern architectures; SAML remains very strong in enterprise SaaS and legacy B2B integrations.

The comparison should not be reduced to old versus new. SAML has rich metadata , mature federations, and consolidated interoperability across many enterprise products. OIDC offers better alignment with APIs, modern libraries, and JSON tokens. An organization can operate both for many years, using an identity broker to translate protocols and centralize policies.

Translation between SAML and OIDC is not mere syntactic conversion. NameID , subject, attributes, AuthnContext , acr, amr, session and logout have different semantics. The broker needs explicit mappings, trust policy, and observability so that the authentication guarantee is not degraded during the transformation.

radio_button_unchecked 19.15 SAML in API Gateways and Identity Brokers

API Gateways typically secure APIs with OAuth, JWT, mTLS tokens, or technical credentials. SAML can appear in developer portal authentication, administrative console login, or as an identity broker input protocol. When a SAML application needs to call APIs, the common pattern is to exchange the federated session with an appropriate access token, and not send the SAML Assertion directly to all backends.

Some gateways can validate SAML assertions, extract attributes and transform them into context or internal tokens. This capability must be used with care: the gateway needs to validate signature, issuer, audience, recipient, time and replay with the same rigor as an SP . You should also avoid turning generic attributes into broad privileges without explicit policy.

In hybrid architectures, a broker can receive SAML from partners and issue OIDC/OAuth for modern applications. This bridge reduces the need for each API to understand XML Signature, but focuses trust on the broker. Logs must record external issuer, federated subject, authentication method, mappings and issued token, preserving end-to-end traceability.

radio_button_unchecked 19.16 Threats and hardening

The main threats include assertion replay, invalid signature or wrong element, unexpected issuer acceptance, inadequate audience, open ACS , XML Signature Wrapping , XML parser vulnerable to external entities, weak algorithms, tampered metadata , session theft, open redirect via RelayState and insecure attribute mapping.

Hardening starts with IdP and SP allowlists, authenticated metadata , modern algorithms, accurate endpoint validation, unique IDs, replay caches, tight clock tolerance, and fail closed. The XML parser must disable DTD and external entities. The application should only process signed elements and reject messages with ambiguous structure, duplicate signatures or unexpected references.

The operation also matters. Certificates need inventory, alerts, and rotation with overlap. Clocks must use reliable synchronization. Attribute and NameID changes require regression testing. Logs should not store complete assertions unnecessarily, because they may contain personal data and authentication information.

radio_button_unchecked 19.17 Evidence-driven troubleshooting

Troubleshooting must identify the exact point in the flow: creation of the AuthnRequest , redirection, authentication at the IdP , issuance of the Response, delivery to the ACS , cryptographic validation, attribute mapping or session creation. Browser, gateway, and application errors may appear similar, so request IDs, timestamps, entityIDs, and endpoints are essential.

Messages such as invalid signature can result from incorrect certificate, canonicalization, altered XML, disallowed algorithm, or checking the wrong element. Audience invalid points to divergent entityID . Recipient mismatch indicates different ACS . Response expired could be a misaligned clock, long queue or small window. InResponseTo unknown points to lost state, multiple nodes not sharing a session, or unsolicited response.

Capture tools must be used in authorized environments and with care not to expose assertions. The ideal diagnosis compares active metadata , request issued, response received, selected certificate and application configuration. In clusters, check affinity, request ID storage, and clock for all nodes.

radio_button_unchecked 19.18 Case studies and labs

Case Study 1: A company integrates its corporate IdP with an external SaaS. SP requires persistent NameID and specific groups. The team defines two-sided metadata , signing certificates, attribute mapping, rotation window, and multi-unit user testing. The project initially failed because the email was used as an immutable key; the fix adopts stable identifier and controlled migration.

Case study 2: a banking portal accepts partners via SAML and converts the identity into internal tokens for APIs. The broker validates the assertion , applies issuer policy and AuthnContext , maps the external subject to a partner application and issues access token with restricted audience. The gateway never receives the original assertion on the backends, reducing XML exposure and centralizing federation.

Case Study 3: An SP cluster experiences intermittent InResponseTo failures. The cause is local storage of the AuthnRequest on each node without shared affinity or session. The browser starts at one node and returns to another. The fix uses distributed storage of pending requests and maintains replay cache throughout the validity window.

Suggested labs

1) Examine IdP and SP metadata and identify entityID , ACS , SSO, SLO and certificates. 2) Decode an AuthnRequest and a Response from the laboratory environment. 3) List all validations in addition to the signature. 4) Simulate certificate rotation with overlapping period. 5) Compare a SAML flow with Authorization Code + OIDC.

radio_button_unchecked Chapter summary

SAML 2.0 is an XML federation framework based on assertions, protocol messages, bindings, profiles and metadata . Its most common use case is Web Browser SSO between an Identity Provider and a Service Provider. The IdP authenticates the principal, issues claims, and the SP validates the message before creating its own local session.

Security depends on much more than a valid signature. Issuer, audience, recipient, destination, InResponseTo , time, SubjectConfirmation , replay, XML structure and metadata need to be validated coherently. XML Signature Wrapping and insecure parsing demonstrate why mature libraries and effectively signed element processing are indispensable.

SAML remains relevant in enterprise and B2B federations, while OpenID Connect is a better fit for modern applications and APIs. Identity brokers enable coexistence and translation, but need to preserve semantics and traceability. On API platforms, SAML typically authenticates users to portals or enters the broker, which then issues appropriate tokens to the APIs.

Next step of the course

Chapter 20 will delve deeper into Identity Federation and Single Sign-On as an architecture, comparing trust domains, brokers, home realm discovery, provisioning, lifecycle and coexistence between SAML, OpenID Connect and other mechanisms.

radio_button_unchecked Implementation and review checklist

• EntityIDs, endpoints, and bindings come from trusted, versioned metadata .
• AuthnRequest IDs are unique and stored until Response correlation.
• ACS accepts only registered destinations and rejects messages for another recipient.
• The library validates XML Signature and the application consumes exactly the signed element.
• Issuer, audience, destination, recipient, InResponseTo and temporal conditions are checked.
• Processed assertions are recorded in the replay cache during the required window.
• XML Parser disables DTD, external entities and dangerous constructions.
• NameID and attributes have a semantic, cardinality and origin contract.
• Mappings of groups to permissions follow least privilege and have tests.
• Certificates have inventory, monitoring, overlay, and rollback plan.
• Local Session uses secure cookies and does not rely solely on Single Logout.
• Logs preserve correlation without storing unnecessary personal data.

radio_button_unchecked Exercises

• Differentiate between assertion , protocol message, binding , profile and metadata .
• Describe the SP -initiated SSO flow and indicate where InResponseTo is validated.
• Explain why a valid signature is not sufficient to accept an assertion .
• Compare HTTP-Redirect, HTTP-POST, HTTP-Artifact and SOAP bindings.
• Explain the role of AudienceRestriction, Recipient and SubjectConfirmationData.
• Differentiate between Response signature and Assertion signature.
• Describe XML Signature Wrapping and the main defense rule.
• Propose certificate rotation without downtime.
• Compare persistent, transient and emailAddress NameID .
• Explain why SLO may partially fail.
• Compare SAML 2.0 and OpenID Connect in an enterprise architecture.
• Design a SAML to OAuth/OIDC bridge using an identity broker.

radio_button_unchecked Glossary

radio_button_unchecked Technical references

• OASIS. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0.
• OASIS. Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0.
• OASIS. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0.
• OASIS. Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0.
• OASIS. Security Assertion Markup Language (SAML) V2.0 Technical Overview.
• OASIS. SAML V2.0 Metadata Interoperability Profile Version 1.0.
• W3C. XML Signature Syntax and Processing.
• W3C. XML Encryption Syntax and Processing.
• OWASP. SAML Security Cheat Sheet.
• NIST. Digital Identity Guidelines, when applicable to the context of authentication and federation.

Update note

SAML 2.0 is a stable standard, but products, allowed algorithms, interoperability profiles, and hardening practices continue to evolve. Before deploying, validate official documentation for the IdP , SP , gateway and library used, including signing behavior, metadata and rotation.