Default /logout doesn't work when securityMatcher used in Spring Security 6

[tonybob-tl]

In Spring Security 6, (specifically Spring Boot 3.2, Spring MVC with Thymeleaf in my case) when securityMatcher is used, the default /logout POST or GET stops working. You need to provide a custom logout with a URL that is a child to the securityMatcher's URL.

Described the issue with example code at: stack overflow with workaround

Not sure if this issue is by design or not. Also, not sure if there is a better solution than I provided in the stack overflow. However, it would be good to indicate the need for the custom logout in the documentation so folks don't have to figure it out on their own.

[sjohnr]

@tlarsonlgdor thanks for the report.

The docs describe using securityMatcher in conjunction with multiple filter chains, which is always the intended way to configure Spring Security when part of the application requires specific security. Otherwise, you should omit securityMatcher since it doesn't make sense to intentionally limit Spring Security's coverage of requests. Spring Security's defaults assume the entire application is being secured, and always requires customization if this is not the case (which I believe should be uncommon). Does your use case truly require securing only part of the application?

Does the suggestion to define multiple filter chains seem unclear based on the docs linked above? Do you feel like this part of the docs could be improved? Is there another part of the docs where you feel the information you mention should be added?

[tonybob-tl]

@sjohnr thanks for the response.
Yes. I am in need of multiple filter chains as I have two different user tables (actually mongo collections) and two different authorization processes in my app. However, I assumed the default logout process could be shared, which apparently it can't.

Regarding the documentation, in my case, I have a custom login in the first (Order(1)) chain instead of httpBasic as shown in the documentation, so apparently I needed a custom logout too. I can't comment on documentation cause I'm not sure whether both or one of the chains will logout properly in the example discussed there. However, it might be nice to make a note somewhere about what defaults stop working with the securityMatcher.

In general, further discussion of how to use multiple tables and multiple authorization processes with the securityMatcher would be good. Much of the stackoverflow/Baeldung documentation online is outdated. I've figured out how to use AuthenticationManagerResolver and AuthenticationFilter with my two user tables and two login processes from Baeldung, but it took some back engineering and trial & error and I'm not sure it is best practice with the securityMatcher. Using AuthenticationUserDetailsService with filters on the chain to accommodate different logins might be a better solution for my case, but couldn't find any documentation on it.

[sjohnr]

@tlarsonlgdor thanks for the reply! There's a few things to discuss about what you mentioned.

I assumed the default logout process could be shared, which apparently it can't.

Whether a logout process can or can't be shared between two different authentication mechanisms and/or different sets of endpoints depends heavily on the authentication mechanism used. If (for example) both mechanisms end up using sessions, the logout mechanism should be reusable in most cases. If you're not using sessions, logout likely wouldn't apply for whichever isn't using sessions.

Regarding the documentation, in my case, I have a custom login in the first (Order(1)) chain instead of httpBasic as shown in the documentation, so apparently I needed a custom logout too. I can't comment on documentation cause I'm not sure whether both or one of the chains will logout properly in the example discussed there.

The httpBasic authentication is stateless by default (in Spring Security 6) and doesn't use a session (though CSRF might if it is enabled). Because of this, you can't really log out. I don't know how your authentication works so I can't say, but you may have something off in the implementation if logout can't be shared. Can you share the details?

However, it might be nice to make a note somewhere about what defaults stop working with the securityMatcher.

I feel this statement is based on something related to a misconfiguration on your end. While overriding certain defaults in the SecurityFilterChain do turn off some features, this is typically well documented. What I'm trying to get at here is whether you feel like the use of securityMatcher to scope the filter chain requires discussion of customizing endpoints like login or logout. It might be good to add something about this.

In general, further discussion of how to use multiple tables and multiple authorization processes with the securityMatcher would be good.

I think this would fall under the category of a "how-to guide" more than reference documentation. The reference doesn't typically pull together specific use-cases and show an all-inclusive example of how to achieve this, but a how-to guide might. Can you outline your requirements for multiple chains in more detail so we can have an example to work off of for this? I don't know yet where such a guide could live but it is a good start to get the details.