Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to store authn_request.uuid for InResponseTo comparison #172

Open
Jamedjo opened this issue Nov 8, 2018 · 0 comments
Open

Ability to store authn_request.uuid for InResponseTo comparison #172

Jamedjo opened this issue Nov 8, 2018 · 0 comments

Comments

@Jamedjo
Copy link

Jamedjo commented Nov 8, 2018

I'd like to verify that certain requests were initiated from the service provider, rather than being unsolicited ones from the IdP. I'd like to do this by storing authn_request.uuid from #request_phase and then later comparing this to InResponseTo. This might involve matches_request_id, or might bypass that to sometimes allow unsolicited IdP initiated requests.

The SAML protocols spec section on 4.1.4 Use of Authentication Request Protocol includes the following:

4.1.4.3 Message Processing Rules
Regardless of the SAML binding used, the service provider MUST do the following:
• ...
• Verify that the InResponseTo attribute in the bearer <SubjectConfirmationData> equals the ID of its original <AuthnRequest> message, unless the response is unsolicited (see Section 4.1.5), in which case the attribute MUST NOT be present

Unfortunately I don't have any way to access authn_request.uuid during the request phase to make this work.

smarek added a commit to smarek/omniauth-saml that referenced this issue Jan 14, 2020
Because of ticket omniauth#172
Gitlab includes copy of omniauth-saml/lib/omniauth/strategies/saml.rb in sources
https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/omni_auth/strategies/saml.rb

This implementation handles setting the fields not in method request_phase, but in method with_settings
based on caller method name, which might not be 100% reliable
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

No branches or pull requests

1 participant