SAML SSO Security Testing: Assertions, Signatures, and Tenant Mapping

Short answer

SAML SSO testing is not just asking whether an XML signature is valid. A Service Provider (SP) must prove that the validated assertion came from the expected IdP, was issued for this SP, is current, and maps to the correct user and tenant. An application can contain signature validation and still enable account takeover if it uses the wrong assertion inside a signed response.

SAML carries enterprise identity into SaaS and forms a critical trust boundary. Assess metadata, certificates, XML parsing, browser bindings, and user provisioning together. Do not stop after confirming that the IdP can complete a successful login.

Separate SP-initiated and IdP-initiated flows

Inventory supported flows and each tenant’s Entity ID, ACS URL, IdP issuer, and certificate source. In an SP-initiated flow, bind the response to the request with InResponseTo. If IdP-initiated SSO is enabled, review unsolicited-response risk and why it is needed; disable or constrain it where possible.

Check that Destination, Recipient, Audience, NotBefore, NotOnOrAfter, and subject-confirmation fields match expected values exactly. Reject assertions intended for another SP, responses sent to another ACS, future-valid assertions, and expired messages. Define a bounded clock-skew allowance.

XML signatures and parser behavior

The XML element whose signature is validated must be the same assertion the application uses for identity. In an XML Signature Wrapping scenario, an attacker may leave a valid signed assertion in the document and add a second attacker-controlled assertion. If the application selects the wrong node, validation can appear to succeed. Validate against trusted local schemas and ensure the parser does not load external entities or unexpected remote schemas.

The SP should trust only the IdP certificate registered for that tenant. Do not let an assertion’s KeyInfo choose the verification key. Define allowed signature and digest algorithms; test rejection of deprecated algorithms such as SHA-1, and review certificate validity and rollover behavior.

Replay and tenant/user mapping

Try the same assertion in another browser session and a second time. A replay cache or equivalent use tracking for response and assertion IDs should prevent reuse throughout the validity window. An assertion signed by Tenant A’s certificate must not work for Tenant B’s SSO connection.

Email equality alone does not prove account linking or tenant membership. Review how stable identifiers such as issuer + subject are stored in tenant context. For domain matching, invitations, just-in-time provisioning, and SCIM, ensure role defaults do not grant excess privilege. Define when access and existing sessions are revoked after an IdP user is deleted or the tenant connection is removed.

Metadata, certificate rotation, and operations

If metadata is fetched automatically, review its origin, TLS validation, update frequency, and approval process. Remote metadata must not silently widen trust by adding an unexpected endpoint or certificate. Plan a bounded overlap period for old and new signing keys during rollover; do not leave an indefinite trust list.

SAML responses may contain personal data. Keeping raw XML in debug logs helps investigate login failures but can expose tokens and user details. Log a correlation ID, tenant, verification result, and error code; redact assertion content and signatures.

Assessment sequence

1. Inventory each tenant’s SP/IdP configuration and supported SSO flows.
2. Capture a valid response and vary audience, destination, recipient, timestamps, and request binding.
3. Safely test signature wrapping, duplicate assertions, wrong keys, and algorithms.
4. Verify replay, tenant crossover, account mapping, and provisioning behavior.
5. Test metadata/certificate rotation and IdP outage handling.
6. Report the affected user, tenant, and login impact without sharing raw assertions.

Logout ve oturum eşzamanlılığı

SAML Single Logout desteği varsa SP ve IdP’nin hangi oturum kimliklerini kapattığını, logout mesajının imza ve destination kontrollerini ve bağlantı kopması davranışını test edin. Bir IdP oturumu kapanırken SaaS uygulamasının yerel oturumu aktif kalabilir; sistem bu davranışı ürün politikasına göre açıkça yönetmelidir. Kullanıcı tenant’tan kaldırıldığında açık browser oturumu, refresh/session cookie ve uzun yaşayan API token’larının hangi gecikmeyle etkisiz kaldığını ölçün.

Bir kullanıcının birden çok tenant’ta aynı IdP ile oturum açması da test matrisinde olmalıdır. SSO callback’inin hangi tenant yapılandırmasını seçtiği, e-posta domain’ine göre tahmin edilmek yerine request state veya açık tenant seçimiyle güvenli biçimde belirlenmelidir. Yanlış tenant’a düşen giriş, doğru assertion imzasına rağmen yetki sınırı ihlali yaratabilir.

For an assessment of SAML and other login flows alongside application controls, see our application security testing service.