Signing and Encrypting SAML Assertions: A Guide

Signing and Encrypting SAML Assertions

In the SAML 2.0 ecosystem, the security of an identity assertion does not end when it leaves the Identity Provider (IdP). While Transport Layer Security (TLS) protects the assertion during HTTP transport, it offers no protection once the Service Provider (SP) receives it. If an attacker compromises the SP’s local storage or intercepts a log file, a plaintext SAML assertion reveals the user’s identity and attributes in clear text, and without integrity checks, allows for trivial tampering.

To secure SAML assertions, engineers must implement two distinct XML-level mechanisms: saml signing via XML Signature (for integrity and authentication) and XML Encryption (for confidentiality). These mechanisms operate on the XML Document Object Model (DOM), not the HTTP transport.

This article is Part 4 of the SAML 2.0 for Engineers series.

The Vulnerability Gap

Consider a typical SSO flow. The IdP generates a <saml:Assertion> containing a <saml:NameID> and attributes like email and role. This assertion is base64-encoded and placed in the SAMLResponse parameter of an HTTP POST. TLS ensures this POST cannot be modified in transit. However, if the SP stores this response in a session store or logs it for auditing, the data is exposed to anyone with read access to that storage. Furthermore, if an attacker can inject a malicious assertion into the SP’s processing pipeline (e.g., via a compromised IdP or a man-in-the-middle who has already decrypted the TLS stream), they can alter the role attribute from user to admin unless the assertion is cryptographically signed.

Therefore, SAML assertions must be self-contained security tokens. They must carry their own proof of origin (signature) and their own protection against eavesdropping (encryption).

XML Signature: Ensuring Integrity

XML Signature (a W3C Recommendation developed jointly with the IETF) allows you to sign any part of an XML document. In SAML, the standard practice is to sign the entire <saml:Assertion> element. This creates a digital fingerprint of the assertion’s content. If any byte changes—whether it’s the issuer, the subject, or an attribute—the signature verification fails.

The Mechanism

When the IdP signs an assertion, it generates a ds:Signature element. This element contains:

1. SignedInfo: A canonicalized, sorted list of what is being signed.
2. SignatureValue: The actual cryptographic signature, generated by hashing SignedInfo and encrypting the hash with the IdP’s private key.
3. KeyInfo: Reference to the IdP’s public certificate, allowing the SP to verify the signature.

<saml:Assertion ...>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
      <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
      <ds:Reference URI="#_uuid-123">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
        <ds:DigestValue>Base64EncodedHash...</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>Base64EncodedSignature...</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MII...CertificateData...</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
  </ds:Signature>
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <!-- Assertion Content -->
</saml:Assertion>

Canonicalization and Signature Wrapping

A critical detail in XML Signature is canonicalization (c14n). XML is flexible; whitespace, attribute order, and namespace declarations can vary without changing the semantic meaning of the document. Without canonicalization, an attacker could alter the formatting of the assertion (e.g., adding spaces or reordering attributes) to create a different byte stream that hashes to a different value, potentially bypassing naive signature checks.

More dangerously, strict signature validation logic—not canonicalization alone—is the primary defense against XML Signature Wrapping (XSW) attacks. In an XSW attack, an attacker appends a new, valid <saml:Assertion> to the original one. If the SP only verifies the first signature it encounters, it might validate the attacker’s fake assertion while ignoring the real one, or vice versa. By enforcing strict validation logic—specifically verifying that the signature covers the specific assertion ID rather than just the first signature found—these attacks are mitigated.

XML Encryption: Ensuring Confidentiality

While signing protects against tampering, it does not hide data. An attacker with access to the assertion can read the NameID and attributes. To prevent this, SAML supports XML Encryption (a W3C Recommendation). This mechanism encrypts the sensitive parts of the assertion so that only the intended recipient (the SP) can decrypt them.

Envelope vs. Enveloped Encryption

There are two primary ways to encrypt a SAML assertion:

1. Enveloped Encryption: The original <saml:Assertion> element is replaced by an <xenc:EncryptedData> element. The rest of the SAML message structure remains intact, but the content is opaque.
2. Envelope Encryption: The encrypted data is wrapped inside a new element, leaving the original assertion structure visible but its content hidden.

Enveloped encryption is more common in SAML because it keeps the SAML message structure predictable for parsers.

The Mechanism

When encrypting, the IdP (or the SP, depending on the flow) generates a symmetric session key (e.g., AES-256) to encrypt the assertion body. This session key is then encrypted using the SP’s public certificate (asymmetric encryption). The resulting structure looks like this:

<saml:Assertion ...>
  <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" 
                      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" />
        <KeyInfo>
          <ds:X509Data>
            <ds:X509Certificate>SP_Public_Certificate</ds:X509Certificate>
          </ds:X509Data>
        </KeyInfo>
        <xenc:CipherData>
          <xenc:CipherValue>Base64EncryptedSessionKey</xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptedKey>
    </KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>Base64EncryptedAssertionBody</xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</saml:Assertion>

The SP receives this, extracts the EncryptedKey, decrypts it using its private key to retrieve the session key, and then uses that session key to decrypt the CipherValue (the actual assertion content).

Selective Encryption

Engineers often choose to encrypt only specific elements within the assertion, such as <saml:Subject> or <saml:Attribute>, rather than the entire assertion. This is known as selective encryption. It allows the SP to still read the Issuer and IssueInstant for routing and timestamp validation without needing to decrypt the whole blob, improving performance while maintaining confidentiality for sensitive user data.

Operational Tradeoffs and Implementation

Implementing SAML signing and encryption requires careful certificate management. The IdP must have access to its private key for signing, and the SP must have access to its private key for decryption. Certificates must be exchanged and configured in both systems’ metadata files.

A common pitfall is clock skew. Since SAML assertions include an IssueInstant and NotOnOrAfter timestamp, and these are covered by the signature, any significant time difference between the IdP and SP will cause signature verification to fail. Engineers must ensure NTP synchronization across all components. As noted in the SAML 2.0 Core Specification (OASIS, 2005), timestamp validation is mandatory for secure assertion processing.

Another consideration is performance. XML signature and encryption operations may introduce latency compared to simpler token formats like JSON Web Tokens (JWT). For high-throughput applications, the overhead of parsing, canonicalizing, and verifying XML signatures can impact response times. However, the security benefits—particularly the prevention of tampering and leakage of identity data—are non-negotiable for enterprise identity management.

Pitfalls

Beyond clock skew and performance, engineers must watch for several common pitfalls:

• Certificate Expiration: Failing to rotate signing and encryption certificates before they expire causes immediate authentication failures. Automated monitoring of certificate validity periods is essential.
• XML Signature Wrapping (XSW): As discussed, improper validation logic can allow attackers to wrap malicious assertions around legitimate ones. Always validate the signature against the specific assertion ID referenced in the Reference URI.
• Plaintext Logging: Storing full SAML responses in logs exposes sensitive user attributes. Ensure that sensitive elements are masked or removed before logging.

Conclusion

SAML assertions are not secure by default. Relying solely on TLS is a critical error. By implementing XML Signature, engineers ensure that assertions cannot be tampered with and originate from a trusted IdP. By implementing XML Encryption, they ensure that sensitive user data remains confidential even if stored or logged. Together, these mechanisms form the foundation of a secure SAML deployment, protecting the integrity and privacy of identity data across the trust boundary.