fix(security): correlate SAML responses to the request that solicited them

[windischb]

A captured, correctly-signed SAML Response could be presented repeatedly within its
NotOnOrAfter window — replay, login-CSRF, session swapping.

Signature validation was enforced, but nothing tied a Response to a request this SP
actually sent: StartLoginAsync discarded the generated AuthnRequest ID,
InResponseTo appeared nowhere in the SAML code, and no Response or Assertion ID was
ever checked against a single-use store. Any genuine Response was therefore acceptable
at any time, any number of times.

Approach

The issued AuthnRequest is persisted as SamlPendingAuthnRequest, and the ACS claims it
via InResponseTo. That delivers correlation and single-use in one mechanism rather
than two: replaying a Response necessarily reuses an InResponseTo that is already
spent, so a separate Response/Assertion-ID replay store would be redundant. It also
binds the Response to the provider it was solicited from, so it cannot be presented at a
different provider's ACS within the same realm.

Modelled on the existing DpopReplayStore, with two deliberate differences:

• The consume is a version-checked Store of a ConsumedAt marker, not a Delete.
  Marten does not version-check deletes, so a load-then-delete consume would let two
  concurrent presentations both succeed. Keeping the row until it expires also lets the
  ACS distinguish "already used" from "unknown id" in the audit trail.
• State lives in the tenant DB, not a cookie. The ACS POST is cross-site, so a
  SameSite=Lax cookie does not arrive — the same constraint that already degrades the
  SAML link-flow — and the check has to hold across every instance serving the realm.

Two decisions worth reviewing

Correlation runs after signature validation, not before. Consuming first would let an
unauthenticated attacker burn a victim's pending request by POSTing a garbage Response
with a guessed InResponseTo, turning a replay defense into a login-denial lever. The
signature is what proves the Response came from the IdP; only then is it worth spending
the pending request on it.

Unsolicited (IdP-initiated) responses are now refused. This is a behaviour change.
It is consistent with what the codebase actually supports — there is no IdP-initiated
entry point and SLO is explicitly out of scope — so requiring InResponseTo matches
reality rather than restricting it. If IdP-initiated SSO is ever wanted, it should be an
explicit per-provider opt-in; I did not build that speculatively.

Testing

Unit 1395/1395, integration 532/532.

New tests cover single-use, concurrent presentation, unsolicited, unknown request,
expired, provider mismatch, and the opportunistic prune — driven against real Postgres.
Verified as real coverage rather than a snapshot of current behaviour: dropping
UseOptimisticConcurrency makes the concurrency test fail, with both racers winning.

Coverage gap, stated plainly: the HTTP ACS path is not exercised end to end, so the
flow's wiring of this store rests on review rather than test. That matters more than
usual here, because the change makes SAML login depend on InResponseTo echoing the
exact ID the SP generated — a mismatch would break every SAML login, not just replays.

A manual dev IdP does exist for this (dev/saml-idp/, simpleSAMLphp via Docker, signs
both Responses and Assertions), it is simply not wired into the automated suite. The
durable fix is an in-process rig that mints signed Responses so the real ACS endpoint can
be driven from tests; that is its own piece of work and would unblock several other SAML
assertions besides this one.

Also adds InternalsVisibleTo for Modgud.Api.Tests on Modgud.Authentication, matching
what Modgud.Api and Modgud.Client.AspNetCore already do, so the test can drive the
store implementation directly.

🤖 Generated with Claude Code