The logoutFilter request matcher is hardcode to POST method

[3rojka]

I have troubles with this hardcoded POST method, as in my application we do not post logout url and only use get, possibility to configure the matcher would be nice. At least I did not found a way to configure that. I had to copy the whole configurer and reimplement just this piece of code.

spring-security/config/src/main/java/org/springframework/security/config/annotation/web/configurers/saml2/Saml2LogoutConfigurer.java

Line 278 in e9449be

RequestMatcher logout = new AntPathRequestMatcher(this.logoutUrl, "POST");

[gourav]

Hello @sjohnr @jzheaux .
This seems like a beginner friendly issue where configurer needs to take an additional parameter for required request method.

If this analysis is correct, may I work on this ?

[3rojka]

There is deeper question about all the configurers, I understand that final classes ar hard to break, but why cannot be configurers overwritten is a mystery to me. I would like to propose considering not to make these classes final and open the for customization. But maybe I am just missing some aspect of possibility to customize it.
I have a decade old application that evolved from application servers to spring boot application, and for its nature I need to be able to do more customization to some of the filters created, while I would like to use the defaults from spring. Then I end up copy pasting whole configurer into my code and overwrite what I need, but I admit that this is really ugly.

[jzheaux]

I think we definitely want to encourage POST /logout since GET /logout is vulnerable to CSRF Logout. I'd prefer that the methods exposed in saml2Logout be for the most secure cases.

That said, I think that we can make this a little easier by allowing the filter to be post-processed as most other filters can already be.

What's needed to do this is change Saml2LogoutConfigurer to wrap the filter in the postProcess method made available by the configurer API like so:

// ...
LogoutFilter logoutFilter = new LogoutFilter(logoutRequestSuccessHandler, logoutHandlers);
logoutFilter.setLogoutRequestMatcher(createLogoutMatcher());
return postProcess(logoutFilter);

Then, an application can do:

http
	.saml2Logout((saml2) -> saml2
		.addObjectPostProcessor(new ObjectPostProcessor<LogoutFilter>() {
				@Override public<O extends LogoutFilter> O postProcess(O object) {
					object.setLogoutRequestMatcher(myRequestMatcher);
					return object;
				}
		})
	);

to override the default to whatever request matching is needed.

Would you be able to submit a PR to allow the logout filter to be post-processed? If you are able, it would also be nice to do it for the two other filters that are added by the DSL.

[3rojka]

yes postprocessing would solve my problem

[gourav]

Hi @3rojka.
I am sorry but are willing to work on this or may I take this up ?

[3rojka]

Take it.

[jzheaux]

Hi, @Erised. Is this something that you are still able to contribute?

[gourav]

Hello @jzheaux. Please review changes in #10339 for this issue.
Kindly let me know the further changes required, I will push those straightaway.

[EkaLinMan]

Hi @jzheaux, I use Spring security 5.8.3 and have a similar issue when using <saml2-logout> in XML configuration,
is there any way to solve it with XML way?
https://github.com/spring-projects/spring-security/blob/5.8.x/config/src/main/java/org/springframework/security/config/http/Saml2LogoutBeanDefinitionParser.java#L166