Describe the bug When using the HTTP-REDIRECT binding the Signature (URL parameters Signature and SigAlg) are not retrieved from the URL.
To Reproduce Use HTTP-REDIRECT binding. The OpenSamlAuthenticationProvider will throw an exception that the response or the assertions are not signed. When looking at the code is seems only an embedded signature in the Response seems accepted (or signed Assertions), but when using the HTTP-REDIRECT binding the Response should not be signed in that way according to the SAML2 specification; the Signature should be in the URL parameters.
We have used Keycloak as an SAML2 IDP. However you must disable the 'force to POST' setting to reproduce. Microsoft ADFS as an IDP will also fail as it will respect the HTTP-REDIRECT binding that is provided in the Service provider metadata XML.
Expected behavior The Signature should be retrieved from the URL when processing a GET request and stored somewhere in the Saml2AuthenticationToken. The signature should then not be expected within the Response when processing the token.
Sample Not available at this moment
Comment From: jzheaux
Thanks for the suggestion, @willemsrb.
The exclusion of HTTP-Redirect support is intentional since it is disallowed by the spec (emphasis mine):
421 In step 5, the identity provider issues a
message to be delivered by the user agent 422 to the service provider. Either the HTTP POST, or HTTP Artifact binding can be used to transfer 423 the message to the service provider through the user agent. The message may indicate an error, 424 or will include (at least) an authentication assertion. The HTTP Redirect binding MUST NOT be 425 used, as the response will typically exceed the URL length permitted by most user agents.
It would be best to move to a supported binding if you can.
If you can't, one thing you could do would be to verify the signature yourself and then re-sign it with an internal key pair. This could be configured as a custom AuthenticationConverter like so:
http
.saml2Login((saml2) -> saml2
.authenticationConverter(myCustomConverter)
);
Comment From: willemsrb
Thanks you very much for the reply. My apologies for not seeing that part of the specification. You are correct and I have configured the POST binding instead.
It would be nice if the relying party configuration would then disallow the usage of this binding for the ACS.
Op di 5 jan. 2021 om 17:07 schreef Josh Cummings notifications@github.com
Thanks for the suggestion, @willemsrb https://github.com/willemsrb.
The exclusion of HTTP-Redirect support is intentional since it is disallowed by the spec http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf (emphasis mine):
421 In step 5, the identity provider issues a message to be delivered by the user agent 422 to the service provider. Either the HTTP POST, or HTTP Artifact binding can be used to transfer 423 the message to the service provider through the user agent. The message may indicate an error, 424 or will include (at least) an authentication assertion. The HTTP Redirect binding MUST NOT be 425 used, as the response will typically exceed the URL length permitted by most user agents.
It would be best to move to a supported binding if you can.
If you can't, one thing you could do would be to verify the signature yourself and then re-sign it with an internal key pair. This could be configured as a custom AuthenticationConverter like so:
http .saml2Login((saml2) -> saml2 .authenticationConverter(myCustomConverter) );
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-security/issues/9325#issuecomment-754731512, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACB476EWX2M3LEHG6M6MRWDSYM2LXANCNFSM4VVFTKBA .
Comment From: jzheaux
Good point, @willemsrb. Would you be able to contribute a PR that asserts that the ACS binding is not Redirect?
Comment From: willemsrb
Sorry for the late answer, but i'll try to do that in the next week if time allows
On Wed, Jan 6, 2021 at 4:13 PM Josh Cummings notifications@github.com wrote:
Good point, @willemsrb https://github.com/willemsrb. Would you be able to contribute a PR that asserts that the ACS binding is not Redirect?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-security/issues/9325#issuecomment-755356825, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACB476ADN3XX2JMNSRAKSFTSYR4YZANCNFSM4VVFTKBA .