Skip to content

fix: bind the assertion to the request this SP issued - #43

Open
shreemaan-abhishek wants to merge 1 commit into
fix/assertion-conditionsfrom
fix/assertion-in-response-to
Open

fix: bind the assertion to the request this SP issued#43
shreemaan-abhishek wants to merge 1 commit into
fix/assertion-conditionsfrom
fix/assertion-in-response-to

Conversation

@shreemaan-abhishek

Copy link
Copy Markdown
Contributor

Part of #37, item 4. Stacked on #42, which brought items 1 to 3; the base branch retargets to main when that merges. Item 5, the assertion replay cache, follows.

What was wrong

generate_saml_id minted an ID for every AuthnRequest and login threw it away. Nothing afterwards tied the response back to a login this SP had started, so an assertion captured from one login stayed usable in any later one.

RelayState does not cover this. It is opaque state this SP chose, it is not signed, and the party replaying an assertion controls their own browser session: start a fresh login to get a matching saml_state, then post the old assertion back with the RelayState that login handed out.

What it does now

login keeps the ID it issued on the session as saml_request_id and clears it on success alongside saml_state. login_callback then refuses:

The second is the one that binds. SubjectConfirmationData sits inside the assertion the signature covers, so an attacker replaying a captured assertion cannot rewrite it. The Response around it is usually left unsigned, so its InResponseTo catches a stray or misdirected answer rather than a deliberate one, which is why both are checked rather than only the outer.

An absent InResponseTo is not enforced, keeping the line #42 drew: an IdP that omits it keeps working.

Tests

TESTs 18 to 20 in t/assertion-conditions.t. TEST 20 builds the response after the SP has issued its request, reading the ID back out of the redirect the SP sent the browser, so it exercises a genuine matching ID rather than a fixture.

Full run on this branch, 60 subtests, all pass. Rebuilt against #42's src/ and lua/ with the new tests kept, the two that should fail do and only those:

Failed 4/60 subtests     # TESTs 18 and 19, body and error log

TEST 20 passes on both, which is the point of it.

login generated an AuthnRequest ID and threw it away, so nothing tied the
response back to a login this SP started. An assertion captured from one
login stayed usable in any later one.

The ID is kept on the session now. A SubjectConfirmationData naming a
different request makes that confirmation unsatisfiable, and a Response
answering a different request is refused outright. The confirmation is the
binding that holds: it sits inside the signature, while the Response
around it is usually unsigned.
@coderabbitai

coderabbitai Bot commented Aug 18, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a2fda71b-180c-4379-9e4c-14cca2e06c7e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant