TL;DR
Encrypted SAML assertion responses aren’t a silver bullet. Attackers can still exploit vulnerabilities in how you handle them, like replay attacks or manipulating the decryption process. This guide shows you how to identify and mitigate these risks.
Understanding the Risks
SAML (Security Assertion Markup Language) is often used for single sign-on (SSO). Encrypting the assertion response protects its contents during transit, but doesn’t prevent all attacks. Here are some common vectors:
- Replay Attacks: An attacker intercepts a valid SAML response and re-sends it later to gain access.
- Decryption Key Compromise: If the private key used for decrypting SAML responses is compromised, attackers can read and potentially modify assertions.
- XML Signature Wrapping Attacks: Attackers manipulate the XML signature within the assertion to inject malicious content.
- Relay Attacks: An attacker intercepts a valid response and forwards it to the intended service provider (IdP), but changes the recipient URL.
Mitigation Steps
- Implement SAML Response Validation: This is your first line of defence.
- Check the Issuer: Verify that the assertion comes from a trusted Identity Provider (IdP).
- Verify Signature: Ensure the assertion hasn’t been tampered with by validating its XML signature. Your SSO software should handle this automatically, but confirm it’s enabled and working correctly.
- Check Conditions: Validate the
IssueInstant(assertion creation time) andNotBefore/Expirestimes to prevent replay attacks.
- Use SAML Request Binding with Authentication Context:
Force clients to use secure bindings like HTTP-POST or SOAP binding for sending SAML requests. Specify a required authentication context (e.g., password protected) in the request.
- Implement Replay Protection Mechanisms:
- Assertion ID Tracking: Store recently processed assertion IDs and reject duplicates. This prevents attackers from replaying intercepted responses.
# Example (pseudocode) - store for a limited time processed_assertions = set() if assertion_id in processed_assertions: reject_request() else: process_assertion(assertion) processed_assertions.add(assertion_id) # Remove old entries after, e.g., 5 minutes - Timestamp Validation: Check the assertion’s timestamp against your system clock and reject requests with significantly outdated timestamps.
- Assertion ID Tracking: Store recently processed assertion IDs and reject duplicates. This prevents attackers from replaying intercepted responses.
- Secure Key Management:
- Protect Private Keys: Store private keys used for decrypting SAML responses in a Hardware Security Module (HSM) or secure key vault.
- Key Rotation: Regularly rotate your decryption keys to limit the impact of a potential compromise.
- Access Control: Restrict access to key management systems to authorized personnel only.
- Monitor for Anomalous Activity:
- Log SAML Events: Log all SAML requests and responses, including issuer, recipient, assertion ID, and timestamps.
- Alerting: Set up alerts for suspicious patterns, such as multiple failed signature validations or unexpected issuers.
- Regular Security Audits & Penetration Testing:
Conduct regular security audits of your SAML configuration and perform penetration testing to identify vulnerabilities.
Example Configuration Checks (Illustrative)
(These will vary depending on your SSO software)
- Okta: Review the ‘Sign-on’ settings for your application. Ensure ‘Signature Validation’ is enabled and configured with trusted IdP certificates.
- Azure AD: Check the SAML configuration in Azure Active Directory. Verify that the ‘Signing Certificate’ is valid and that replay protection is enabled.

