I have a unique scenario I'm trying to resolve under the constraints of the Spring Security plugin (version 1.2.7.3 if currious). I have created a custom SSO plugin that allows login with a signed URL. The custom plugin works great, and I have added according to the documentation by creating the beans in resources.groovy and adding into the filter chain within BootStrap.groovy.
SpringSecurityUtils.clientRegisterFilter('ssoFilter', SecurityFilterPosition.SECURITY_CONTEXT_FILTER.order + 10)
Once a user is signed in everything works great and the existing active session that was added to the security context authenticates the user.
I have a use case where it is possible that a user who is already authenticated may come back on the same browser (i.e. same session cookie) with a different user on an SSO request. I'd like to have the filter chain notice the 'sso=true' in the query string of the URL.
The behavior I'm seeing now is that the SSO is never reached because the original user is already authenticated by the security context. I can't add the SSO filter before the SecurityContextPersistenceFilter as that causes issues where the SSO filter is constantly hit and nothing actually gets rendered. This follows docs where I've seen it saying that you shouldn't put any filters ahead of the security context filter.
I had looked into creating a special filter chain specifically for URLs with 'sso=true' (something I am doing during the unauthenticated flow by adding a custom RequestMatcher and AuthenticationEntryPoint implementation to the DelegatingAuthenticationEntryPoint) by using the springsecurity.filterChain.chainMap config saying. However, it appears from docs and experiments that only the path is filtered.
Is there a way to ensure that whenever 'sso=true' is seen on the URL, that the SSO filter is hit while still having availability to the security context or that the SecurityContextPersistenceFilter can pass through the request to the SSO filter?