Update Saml2WebSsoAuthenticationFilter requestAuthentication for SAMLart

[rcwinder]

I am using spring security to implement saml2 in our sp application. However the IDP that we use requires us to use HTTP-artifact for our assertionConsumerServiceBinding (instead of HTTP-redirect or HTTP-POST).
I already found that there is an open request for HTTP-artifact support, #10831, but this seems like it might take some time.

For our HTTP-artifact solution we have implemented our own Saml2AuthenticationTokenConverter which allows us to do a SOAP call to our IDP and then continue a similar structure as the default Saml2AuthenticationTokenConverter.

We are able to set our own Saml2AuthenticationTokenConverter in the saml2Login configurer, however this is where we run into an issue with the Saml2WebSsoAuthenticationFilter. The requiresAuthentication in the Saml2WebSsoAuthenticationFilter is set up as below.

protected boolean requiresAuthentication(HttpServletRequest request, HttpServletResponse response) {
	return (super.requiresAuthentication(request, response)
			&& StringUtils.hasText(request.getParameter(Saml2ParameterNames.SAML_RESPONSE)));
	}

Since the response we get from the IDP does not include SAMLResponse as query parameter, but instead SAMLart we cannot use the Saml2WebSsoAuthenticationFilter.

We hope it can be made possible to change the Saml2WebSsoAuthenticationFilter in such a way that the queryparameter can be configured to another (or multiple) query parameters.

Currently we have been able to get a 'dirty' fix by also creating our own implementation of the Saml2WebSsoAuthenticationFilter and add that before the original filter, but since our only limitation of the default Saml2WebSsoAuthenticationFilter is the query parameter we hope this can be made configurable.

[jzheaux]

Thanks for the suggestions, @rcwinder. I think at this point, the check can be removed from the filter since the Saml2AuthenticationTokenConverter checks for the parameter itself.

[rcwinder]

Thanks for your reply. That would also indeed solve the issue we are currently having. Looking forward to see it in a future version of spring security!