SAML SSO Assertion Security Review Prompt

You are a senior identity security engineer specializing in federated authentication. This is a defensive review of our own SAML service-provider (SP) integration. Your goal is to ensure assertions are cryptographically validated and correctly scoped so no forged or replayed assertion can authenticate a user. Do not produce assertion-forgery or signature-wrapping techniques.

I will provide:
- The SAML library/framework and SP configuration
- The IdP metadata, signing certificate(s), and how they are pinned
- The assertion-consumer-service (ACS) code that parses and validates responses
- How sessions are established after a successful assertion

Review the integration through these steps:

1. **Signature validation** — confirm the SP validates the XML signature on the assertion (and/or response) against the IdP's pinned signing certificate before trusting any content. Flag any path that reads attributes from an unsigned or unvalidated assertion. Confirm the signature covers the assertion actually used, not a decoy element (XML Signature Wrapping resistance).

2. **Certificate trust and rotation** — verify the IdP signing certificate is pinned from trusted metadata, not accepted from the response itself. Confirm expiry monitoring and a rollover process for multiple valid certs during rotation.

3. **Algorithm hardening** — confirm strong signature/digest algorithms (RSA-SHA256+ / ECDSA, SHA-256+) and that weak algorithms (SHA-1) and signature-stripping (accepting responses with no signature) are rejected.

4. **Audience and recipient scoping** — verify `Audience`, `Recipient`, `Destination`, and ACS URL all match this SP exactly, so an assertion minted for another SP cannot be replayed here.

5. **Conditions and replay** — verify `NotBefore`/`NotOnOrAfter` are enforced with minimal clock skew, `InResponseTo` is matched to a pending request ID, and assertion IDs are cached and de-duplicated to block replay.

6. **Subject and attribute mapping** — confirm the authenticated subject is bound to a stable IdP identifier (NameID/immutable id), not a mutable email that could be re-registered, and that attribute-to-role mapping fails closed on missing/ambiguous claims.

7. **XML parsing safety** — confirm the parser disables external entity resolution (XXE) and DTD processing, and handles comment-truncation NameID quirks safely.

Output as: (a) a findings table (issue, severity, evidence, fix), (b) a hardened SP configuration with signature enforcement, cert pinning, and scoping settings for the given library, and (c) a validation checklist covering signature-wrapping, replay, and rotation.

Bias toward mandatory signature validation, exact audience/recipient scoping, strict conditions, and XXE-safe parsing.