SAML 2.0 penetration testing and signature wrapping

A SAML 2.0 penetration test must answer two separate questions: is the message cryptographically valid, and does the application make its security decision from the exact element that was verified? Severe single sign-on failures often do not break a digital signature. They exploit a disagreement among the XML Signature library, the document parser and the application code that maps an assertion to a user session.

This guide provides a safe technical methodology for assessing a Service Provider, its Identity Provider integration, metadata, signatures, encryption, replay defence and RelayState processing. It is grounded in the OASIS, W3C and OWASP specifications and guidance. Perform the tests only in an authorised environment with accounts controlled by the assessment team.

The SAML 2.0 model in five elements

A typical Web Browser SSO flow involves:

• a user and browser;
• the target application acting as Service Provider (SP);
• an Identity Provider (IdP) that authenticates the user;
• an AuthnRequest created by the SP;
• a Response containing one or more assertions and statements.

In SP-initiated SSO, the application creates a request and redirects the user to the IdP. After authentication, the IdP delivers a response to the Assertion Consumer Service (ACS). The SP validates the structure, signature, time, recipient, audience and relationship with the earlier request before creating a session.

An IdP-initiated flow has no earlier AuthnRequest, so it cannot rely on InResponseTo for request correlation. Unsolicited responses and session confusion are consequently harder to control. Disable this mode when the business does not need it. Where it is required, document the compensating replay and destination controls as a separate security profile.

What exactly is signed in a SAML document

An XML signature can protect the Response, an Assertion, or both, depending on the agreed profile. There is no safe generic rule that says “a valid signature exists somewhere in the document”. The SP must know which element is required to be signed, verify that element using a trusted IdP key, and consume that same verified object.

Three layers matter:

Layer	Assessment question	Failure mode
Cryptography	Does the signature verify mathematically for the referenced element?	modification of signed content
XML structure	Does the reference resolve to one allowed element with a unique ID?	signature wrapping or parser differential
Application logic	Is the session built from that same verified element?	consumption of an unsigned assertion

W3C XML Signature can protect selected document fragments through URI references and transforms. That flexibility requires a restrictive application profile. Every optional location, transform or duplicate element admitted by the parser creates another opportunity for two components to interpret the document differently.

XML Signature Wrapping as a class of flaws

XML Signature Wrapping (XSW) abuses a condition in which the signature still references an original, unchanged element, while the application reads identity data from another element in a modified document structure. The attacker does not forge the signature. The attempt is to make the validator and the business logic look at different nodes.

A defensive implementation should:

• perform strict schema validation using local, trusted XSD copies;
• reject unexpected counts of Response, Assertion, Subject and signature elements;
• require ID uniqueness and resolve a reference to exactly one element;
• select the permitted element by an absolute, profile-specific path rather than “the first assertion”;
• pass only the verified object into identity and session logic;
• reject unexpected extensions that are outside the integration profile.

An XSW test should establish how the parser and SAML library behave, not provide a universal exploit payload. The structure depends on the library, binding and profile. The report needs only a minimal sanitised proof that a session was created from content not protected by the trusted signature.

Libraries can reduce risk, but secure defaults differ and integration code can reintroduce the flaw. Record the library and parser versions, configuration flags and the exact object returned after validation. Retest after upgrades because a parser change may alter ID handling or schema behaviour even when application code is unchanged.

Trust the configured IdP key, not arbitrary KeyInfo

A SAML document may contain KeyInfo, but an SP must not treat any key carried inside an untrusted message as trusted. The verification key must come from approved configuration or authenticated IdP metadata. Otherwise an attacker could sign a self-created response with a self-created key and attach that key to the document.

Assess how metadata is retrieved, how its URL is protected, how the entity is pinned, whether metadata signatures are verified, how long data is cached, how rollover works and how failures are handled. Fetching metadata from a user-influenced address can combine an identity flaw with SSRF and outbound-connection risk. Metadata should not be refreshed without limits in the interactive login path.

During a key rollover, an IdP may publish the old and new certificates concurrently. The SP should accept only keys assigned to the correct entity and intended signing use, then remove the old key after the transition. Manually copied certificates with no owner tend to become permanent exceptions.

Distinguish a certificate used as a container for a public verification key from general Web PKI validation. Many SAML federations establish trust through metadata rather than a public browser CA chain. The important question is whether the key is bound securely to the intended IdP entity and managed through a controlled lifecycle.

Validate the complete Response and Assertion context

A valid signature is only the beginning. The Service Provider must validate the message context. The following fields need explicit tests.

Destination

Is the response intended for the exact ACS receiving it? Compare against a configured endpoint, not a URL reconstructed from an untrusted Host or forwarded header. Reverse proxies and multi-domain deployments need an explicit canonicalisation rule.

AudienceRestriction

Was the assertion issued for this Service Provider? Without audience validation, a response for another application in the same identity ecosystem may be accepted. An entity ID does not have to be a resolvable URL, but matching should follow the precise configured identifier.

Recipient

Does the bearer SubjectConfirmation direct the assertion to the correct recipient? Validate Recipient with the ACS and the SubjectConfirmation time restrictions.

InResponseTo

Do the Response and SubjectConfirmation refer to the request created for the current SP session? Request identifiers should be unpredictable, stored server-side, single-use and bound to the browser’s login transaction.

NotBefore and NotOnOrAfter

Is the assertion valid now? Keep permitted clock skew small and documented. A large skew expands the replay window, while every relevant host needs monitored time synchronisation. Treat NotOnOrAfter as an exclusive upper boundary according to the specification.

Issuer

Does the issuer exactly identify the expected IdP and configuration relationship? A similar domain or an issuer value located only in another unverified element is insufficient.

Status, version and structure

Does the Response use the expected SAML version, success status and profile structure? The implementation must not create a session from an error Response merely because an assertion is present elsewhere in the document.

Test each control independently. If several values are invalid in one message, the assessment cannot show which check caused rejection. A good negative-test suite changes one field at a time and records the security decision without retaining reusable assertions.

Replay: a signed message can still be reused

A signature protects integrity but does not make a message single-use. If a valid Response is copied, a weak SP may accept it again. Store Response and Assertion identifiers in a replay cache for their entire possible validity window, and consume an InResponseTo identifier once.

The cache must cover the entire application cluster rather than one pod’s local memory. Otherwise a second attempt routed to another node bypasses the control. Exercise race behaviour as well: two nearly simultaneous submissions of the same Response should create at most one session.

Do not extend assertion validity merely to hide time-synchronisation or IdP-availability problems. Correct clock and resilience engineering instead of increasing the period during which a captured response remains useful.

Log replay rejection with a non-sensitive message identifier, the SP endpoint and correlation data. Do not log the full assertion because it may contain personal data and an active authentication artefact.

RelayState and login-transaction integrity

RelayState carries application state across the SSO redirect and often represents the post-login destination. If the SP treats it as an arbitrary URL, it creates an open redirect suitable for phishing. If it contains a tenant or role decision without integrity protection, it may permit context manipulation.

A safer design uses a random one-time handle referencing state stored server-side. If RelayState must carry data, authenticate its integrity, apply a short lifetime and allow only known relative destinations. Bind it to the request ID and the session that initiated the login.

Test a missing value, duplicate parameters, alternate encoding, an absolute URL, a network-path reference such as //host, alternate ports and unusual paths. The purpose is to understand canonicalisation and state processing in the authorised environment, not to bypass third-party redirect controls.

The application must not use RelayState as proof that authentication began on a particular tenant or host. That decision belongs to trusted server-side state. Verify that parallel login tabs do not swap transactions or attach one user’s Response to another browser context.

Algorithms, canonicalisation and XML parser security

Define allowed signature, digest and canonicalisation algorithms explicitly according to the library and partner profile. Do not depend on defaults that may change after an update. Reject unknown or disallowed algorithms before expensive processing where the library permits.

Disable unnecessary external-entity and network-loading features in the XML parser. SAML processing should never retrieve resources based on a DTD, schema location or transform supplied by the message. Use local pinned schemas to reduce XXE, SSRF and availability risk.

Limits on document size, element count, nesting depth, reference count and processing time protect the ACS from algorithmic denial of service. This endpoint must parse part of a message before a user is authenticated, so resource controls are a security boundary.

Schema validation also has to precede business use. Validating after the application has already selected a NameID does not protect that selection. Keep parsing, schema validation, signature verification and object consumption in a well-defined order with a single data model.

Does a SAML assertion need encryption?

Signing and encryption serve different objectives. A signature protects authenticity and integrity; encryption limits disclosure of attributes to browser-side or intermediate observers. HTTPS remains mandatory even with an EncryptedAssertion. The decision depends on attribute sensitivity and architecture, but the Service Provider must enforce the agreed profile consistently.

If the integration promises encrypted assertions but accepts plaintext too, an attacker may attempt to downgrade processing to the weaker form. Test whether configuration genuinely requires encryption, how the SP decryption key is stored and rotated, and whether error messages expose cryptographic details.

Avoid sending unnecessary personal or authorisation data in the first place. Attribute minimisation lowers confidentiality impact, reduces coupling between IdP and SP and supports privacy obligations. Encryption does not justify collecting broad directory profiles.

Attribute mapping and account takeover

After SAML validation, the application maps NameID and attributes to a local account. This is a frequent location for critical flaws. An email address is not always stable, unique or verified. Domain changes, case normalisation, aliases and multiple IdPs can attach the subject to the wrong record.

Prefer an immutable subject identifier within a specific issuer. The local key should include at least the IdP/issuer and subject rather than email alone. Just-in-time provisioning must constrain domains, tenant membership and roles. A group attribute must not create an administrator unless the integration contract and an explicit allowlist permit it.

Test an existing account, a new account, a disabled account, a changed email address, two IdPs sending the same email, a missing critical attribute and multiple values in a role field. Connect these results with MFA rollout security and privileged access management.

Deprovisioning matters as much as provisioning. Determine what happens when the user is disabled at the IdP, removed from a group or moved to another tenant. A local privileged role that persists after the federated attribute disappears creates an identity-lifecycle gap.

Single Logout and the local application session

SAML SSO does not finish when the SP creates a cookie. Review Secure, HttpOnly and suitable SameSite attributes, session-ID regeneration after login, maximum and idle lifetimes, and the response to account disablement. A long local session can remain active even though the assertion was valid for only a few minutes.

Single Logout is complex, and not every integration guarantees logout from every service. Document what actually happens. Critical applications may need a central session-revocation mechanism or short revalidation interval regardless of the SLO profile.

Test login CSRF and session confusion around the ACS. The browser should end in a session bound to the transaction it initiated, not simply whichever valid Response arrived at the endpoint. Request correlation and browser-session state are essential here.

SAML 2.0 penetration-testing methodology

1. Draw the trust diagram

Record entity IDs, ACS endpoints, bindings, issuers, signing certificates, required signatures, encryption policy, SP- and IdP-initiated flows, metadata source and account mapping. Identify which controls terminate at a reverse proxy.

2. Capture a controlled baseline flow

Use only a test account. Identify request ID, RelayState, Response, Assertion, signatures, conditions and attributes. Do not place an active Response or personal data in the report.

3. Exercise one condition at a time

Change audience, destination, recipient, issuer, time, request ID, status and structure separately. Expect a safe rejection and a useful audit event with no secrets.

4. Bind signature verification to object use

Confirm the required signature location, ID uniqueness, trusted key source and the exact object used to derive identity. Perform structural parser tests in a controlled environment with size and rate limits.

5. Test replay and concurrency

Submit the same Response sequentially and in parallel through different application nodes. Verify one-time request IDs and a cluster-wide replay cache.

6. Review provisioning and roles

Send controlled attribute variants agreed with the IdP owner. Test account matching, domain restrictions, groups, roles, deprovisioning and tenant separation.

7. Assess monitoring and key rollover

Confirm rejection logs, alerts for an unexpected issuer or audience, IdP signing-key rollover, metadata changes and an emergency process to disable the federation.

8. Retest the actual fixed path

After remediation, run the original proof and adjacent negative cases. A narrow patch that blocks one document layout may leave the underlying “verified object versus consumed object” mismatch in place.

Risk-rating SAML findings

A flaw that creates another user’s or administrator’s session without control of that person’s IdP account is critical. Replay leading to practical session takeover, acceptance of an assertion intended for another SP or trust in an attacker-provided key normally deserves high priority. A RelayState open redirect usually receives a different rating unless it combines with token exposure or a compelling phishing chain.

Separate these categories in the report:

• end-to-end identity manipulation demonstrated safely;
• a missing control proven by a focused negative test;
• a configuration that raises risk without confirmed takeover;
• a hardening or operational-resilience recommendation.

This avoids inflated severity and helps the engineering team remediate in order of actual impact. Evidence collection and retesting should align with a web penetration-testing methodology and OWASP ASVS 5 implementation.

Service Provider security checklist

• Require the signature on the exact element specified by the profile.
• Resolve verification keys from trusted configuration or metadata, never arbitrary KeyInfo.
• Validate against local schemas and reject unexpected document structures.
• Enforce unique IDs and consume the verified object.
• Check issuer, destination, audience, recipient, time and status.
• For SP-initiated SSO, require a one-time InResponseTo bound to the browser session.
• Maintain a cluster-wide replay cache.
• Restrict RelayState to integrity-protected state and approved destinations.
• Map users with a stable identifier scoped to the issuer.
• Constrain JIT provisioning, groups and roles through an allowlist.
• Monitor metadata, certificate rollover and validation failures.
• Retest after SAML-library or XML-parser updates.

Frequently asked questions

Is a signed SAML Response always safe?

No. The application must require a signature in the correct location, trust the intended key and consume the verified Assertion. Audience, Recipient, time and replay controls still apply.

Does assertion encryption replace a signature?

No. Encryption protects confidentiality, while a signature provides authenticity and integrity. A profile may require both, and HTTPS remains mandatory.

Can email be used as the account identifier?

Email alone is usually insufficient. Scope a stable subject to its issuer and handle address changes and multiple IdPs explicitly.

Is IdP-initiated SSO automatically vulnerable?

No, but it lacks a preceding request and strong correlation to an initiating session. It needs a distinct risk model, replay defence and destination controls.

Test SSO as a complete identity system

Breachroad assesses SAML across the XML parser, cryptography, protocol conditions, account mapping, application sessions and IdP key lifecycle. Combining that work with Active Directory security testing and application assessment demonstrates impact from a weak federation decision through access to protected data—without unnecessary production risk.

Primary standards and guidance

• OASIS SAML 2.0 Core
• OASIS Profiles for SAML 2.0
• OASIS SAML 2.0 Technical Overview
• W3C XML Signature Best Practices
• OWASP SAML Security Cheat Sheet