SAML (Enterprise SSO)

SAML is enterprise SSO where an Identity Provider (IdP) sends a signed assertion to a Service Provider (SP) saying who the user is. The SP validates it and creates a local session.

Mental model

1. User goes to the SP (your app) and is redirected to the IdP to login.
2. IdP returns a signed SAMLResponse containing an assertion (subject + attributes + time bounds + audience).
3. SP validates signature and checks issuer/audience/time constraints, then creates a session for the user.

• Assertion: identity and attributes.
• Signature: authenticity and integrity.
• Audience/Recipient: which SP/app the assertion is meant for.
• Time conditions: NotBefore / NotOnOrAfter; helps reduce replay risk.

Practical note: auth breaks most often at the seams — redirects, token storage, callback handling — not in the login form itself.

Common failure modes (what goes wrong)

A) Signature validation mistakes

• Root cause: validating the wrong element, accepting unsigned assertions, or not pinning to the correct IdP certificate.
• How attackers think: “Can I get the SP to accept an identity without a valid signature path?”
• Defense: use a vetted library; validate the correct signed element; pin IdP cert; fail closed.

B) Issuer/Audience/Recipient gaps (token confusion)

• Root cause: SP does not enforce issuer/audience or accepts too broad values.
• Impact: assertion intended for another app/tenant can be accepted.
• Defense: strict issuer + exact audience/recipient per environment/tenant.

C) Replay protections missing

• Root cause: SP doesn’t track assertion IDs / InResponseTo and relies only on time window.
• Impact: captured SAML responses can be reused within window if other controls are weak.
• Defense: enforce short validity + track assertion IDs + one-time use + session rotation.

D) XML parsing hardening missed (defense-in-depth)

• Root cause: unsafe XML parser configuration (DTD/entities enabled).
• Defense: disable DTD/entities; use hardened parser defaults; library support matters.

Defensive patterns (Node.js concepts)

Vulnerable pattern (minimal)

// ❌ Concept: parse SAML and trust attributes without strict validation
app.post("/sso/saml", (req, res) => {
  const samlResponse = req.body.SAMLResponse;
  const profile = parseAssertion(samlResponse); // not proven safe
  req.session.userEmail = profile.email;
  res.redirect("/app");
});

Defensive pattern: vetted library + pinned config + replay protection

// ✅ Concept (library-specific details omitted):
// - Pin IdP certificate(s)
// - Validate signature on the correct element
// - Enforce issuer + audience/recipient
// - Enforce time conditions
// - Track assertion ID / InResponseTo to prevent replay
// - Rotate session on login

async function handleSaml(req, res) {
  const result = await saml.validatePostResponse(req.body); // library handles XML safely
  // result.profile has validated subject/attributes
  await replayStore.assertNotSeen(result.assertionId);      // one-time use
  req.session.regenerate(() => {
    req.session.userId = mapToLocalUser(result.profile);
    res.redirect("/app");
  });
}

Safe validation (defensive verification)

• Confirm signature verification is enabled and pinned to correct IdP certificate(s).
• Confirm issuer and audience/recipient are strictly checked per environment/tenant.
• Confirm time bounds are enforced with small clock tolerance.
• Confirm replay protection: assertion ID / InResponseTo is tracked and rejected on reuse.
• Confirm safe XML parser settings (DTD/entities disabled) as defense-in-depth.
• Confirm session rotation on SSO login and step-up for sensitive actions.

Interview Questions & Answers (Easy → Hard)

Easy

1. What is SAML used for?
   A: Plain: enterprise SSO. Deep: IdP issues signed assertions; SP validates and creates local session.
2. IdP vs SP?
   A: Plain: IdP logs users in; SP is the app. Deep: SP must validate assertion signature and constraints before trusting identity.
3. What is a SAML assertion?
   A: Plain: a signed identity statement. Deep: contains subject, attributes, audience, and time bounds.
4. Why do we validate signatures?
   A: Plain: to ensure it’s from IdP. Deep: prevents accepting modified/forged identity data.
5. What is audience/recipient?
   A: Plain: who the assertion is for. Deep: prevents token confusion between apps/tenants.
6. What is replay in SAML?
   A: Plain: reusing a response. Deep: mitigate with short validity + assertion ID tracking.
7. Why rotate session after SSO?
   A: Plain: prevents fixation. Deep: binds identity to a fresh session.

Medium

1. Scenario: signature checked but audience not enforced. Risk?
   A: Plain: wrong assertion accepted. Deep: cross-app/tenant token confusion; enforce exact audience/recipient.
2. Scenario: no replay store. What’s missing?
   A: Plain: one-time use control. Deep: track assertion IDs/InResponseTo; reject reuse.
3. Scenario: multiple IdP certs. How do you manage rotation?
   A: Plain: overlap briefly. Deep: accept old+new certs with monitoring, then retire old with tests.
4. Follow-up: XML hardening—what do you do?
   A: Plain: disable risky features. Deep: disable DTD/entities; rely on a hardened library.
5. Scenario: attribute mapping. What can go wrong?
   A: Plain: wrong account mapping. Deep: enforce stable identifiers; avoid trusting mutable fields like display name.
6. Follow-up: how do you handle logout?
   A: Plain: destroy session. Deep: local logout always; SLO optional but complex—prioritize local revocation.
7. Scenario: multi-tenant SP. What extra checks?
   A: Plain: tenant scoping. Deep: issuer/audience per tenant and safe account linking controls.

Hard

1. How do you detect mis-validation paths?
   A: Plain: centralize validation. Deep: single library entry point + tests covering all SAML endpoints; deny unknown flows.
2. What’s the biggest operational risk in SAML?
   A: Plain: configuration drift. Deep: cert rotation and audience changes; mitigate with automation and regression tests.
3. How do you prevent cross-tenant SSO mistakes?
   A: Plain: strict separation. Deep: per-tenant issuer/audience and strong subject mapping + step-up on tenant changes.
4. What telemetry helps?
   A: Plain: watch failures. Deep: signature failures, audience mismatches, replay detections, unusual assertion rates.
5. Scenario: incident after IdP compromise. Response?
   A: Plain: contain. Deep: revoke sessions, tighten validity, rotate certs, audit suspicious logins.
6. Follow-up: why use SAML over OIDC?
   A: Plain: enterprise legacy. Deep: many orgs standardized on SAML; OIDC is newer and often preferred for modern apps.

Exploitation progression (attacker mindset)

• Find the SAML endpoint: where is SAMLResponse posted?
• Look for validation gaps: signature not enforced, wrong element verified, issuer/audience unchecked.
• Look for replay gaps: assertion IDs not tracked; long validity windows.
• Look for config drift: multiple tenants/apps sharing weak settings, stale cert pinning, broad audiences.
• Chain impact: session takeover, cross-tenant access, account linking abuse.

Checklist

• Signature verification enabled; correct element validated; pinned IdP cert(s).
• Strict issuer + audience/recipient checks (no broad matching).
• Strict time bounds; minimal clock tolerance; short assertion validity.
• Replay protection: track assertion IDs / InResponseTo; one-time use.
• Safe XML parsing (DTD/entities disabled) defense-in-depth.
• Session rotation on login; step-up for sensitive changes.

Remediation playbook

1. Move to a vetted SAML library with secure XML parsing defaults.
2. Pin IdP certificate(s) and enable strict signature verification on the correct element.
3. Enforce strict issuer + audience/recipient checks per env/tenant.
4. Add replay store for assertion IDs/InResponseTo; tighten validity window.
5. Rotate session on SSO login; harden account linking/change flows with step-up.
6. Add regression tests for wrong issuer/audience, unsigned responses, expired assertions, and replay attempts.