Skip to content

Don't clear state on SAML responses or error pages - #137

Closed
jorissteyn wants to merge 1 commit into
developfrom
feature/dont-clear-state-on-saml-response
Closed

jorissteyn wants to merge 1 commit into
developfrom
feature/dont-clear-state-on-saml-response

Conversation

@jorissteyn

Copy link
Copy Markdown
Contributor

When Stepup renders a SAML response or error page, the state of the
request is never reset. If for whatever reason the request to the
consume-assertion request happens twice, both requests succeed. Also,
if the user refreshes the error page, the exact same error
occurs. This is intended behaviour and a good thing.

When Stepup acts as a proxy for GSSP, the behaviour is different. The
state is cleared after consume-assertion and when rendering an error
page. When the error page is refreshed by the user, different errors
are triggered because the request does not match the state. For
example, this error might be logged when refreshing an error page:

Invalid Argument, parameter "requestId" should be of type "string", "NULL" given

This commit changes the proxy controllers to never reset the state
when a request is handled. The behaviour in Stepup is now consistent.

When Stepup renders a SAML response or error page, the state of the
request is never reset. If for whatever reason the request to the
consume-assertion request happens twice, both requests succeed. Also,
if the user refreshes the error page, the exact same error
occurs. This is intended behaviour and a good thing.

When Stepup acts as a proxy for GSSP, the behaviour is different. The
state is cleared after consume-assertion and when rendering an error
page. When the error page is refreshed by the user, different errors
are triggered because the request does not match the state. For
example, this error might be logged when refreshing an error page:

    Invalid Argument, parameter "requestId" should be of type "string", "NULL" given

This commit changes the proxy controllers to never reset the state
when a request is handled. The behaviour in Stepup is now consistent.
@jorissteyn
jorissteyn requested review from MKodde and pmeulen March 9, 2018 08:14
]);

// clear the state so we can call again :)
$stateHandler->clear();

@pmeulen pmeulen Mar 9, 2018 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Part of the state is the ID from the SAML AuthnRequest. This is used for replay protection. The ID from the AuthnRequest must match the InResponseTo in the Response. It is correct to invalidate the ID after receiving a SAML Response. So resending a SAML Response could result in a different error.

I agree that from a user and support perspective it is nice if reloading an error page does not change the error. But this behaviour can be achieved by other means (e.g. by redirecting to an error URL).

@jorissteyn jorissteyn Mar 9, 2018 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, the proper solution is a bit more complicated. I'm closing (and not merging) this PR and created a pivotal issue for further discussion on how to handle this in the future: https://www.pivotaltracker.com/story/show/155850805

@jorissteyn jorissteyn closed this Mar 9, 2018
@jorissteyn
jorissteyn deleted the feature/dont-clear-state-on-saml-response branch March 9, 2018 11:29
kayjoosten added a commit that referenced this pull request Jul 30, 2026
…icate

Per Johan's review comment: this sanitization logic (truncate to 40 chars +
ellipsis, whitespace collapse, control-char strip) existed as three
independently-drifting copies (Gateway, Stepup-gssp-bundle, Stepup-Webauthn),
one of which truncated to 41 chars instead of 40. Moved the canonical
implementation to Stepup-saml-bundle, which both Gateway and gssp-bundle
already depend on. gssp-bundle's own copy is removed in a companion PR
(OpenConext/Stepup-gssp-bundle#49) so its ServiceNameResolver delegates to
the same class - WebAuthn/DemoGSSP/Tiqr need no changes, they already only
call gssp-bundle's ServiceNameResolver, never the formatter directly.

Temporarily pinned to Stepup-saml-bundle's feature/issue-48-mdui-chunk branch
(OpenConext/Stepup-saml-bundle#137, still open) via a VCS repository entry,
matching the same pattern already used in gssp-bundle#49. Needs swapping to
a tagged release once #137 merges.
kayjoosten added a commit that referenced this pull request Aug 3, 2026
surfnet/stepup-saml-bundle 7.1.0-beta1 (PR #137's branch tip) is now tagged,
so this no longer needs to float on a dev-branch requirement.

Verified: composer test (287/287), phpstan, phpcs all pass.
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.

2 participants