Describe the bug
Spring Security, even if configured with SessionCreationPolicy.NEVER or SessionCreationPolicy.STATELESS creates a session when using RequestHeaderAuthenticationFilter.
It may be caused by the change here 4479cef#diff-b9376389ef77383ad282c387359020ed122ad52d641cf25de70f104deae213d8R113
that changed AbstractPreAuthenticatedProcessingFilter to use a HttpSessionSecurityContextRepository by default, but fails to configure it properly with allowSessionCreation=false when using a SessionCreationPolicy that should not create sessions.
Also, when using NEVER the credentials may be read from the session (as expected) but with precedence over the headers sent in the request, which should be the source of truth.
This may affect all subclasses of AbstractPreAuthenticatedProcessingFilter and also other classes that started to use HttpSessionSecurityContextRepository by default in the commit mentionned above, but I didn't test this.
To Reproduce
- Configure an application with a
RequestHeaderAuthenticationFilter and SessionCreationPolicy.NEVER or SessionCreationPolicy.STATELESS in the SecurityFilterChain.
- Make an HTTP call with a
SM_USER header.
Note that using MockMvc still creates the session, as we can see with a debugger, but doesn't seem to set the Set-Cookie header.
Expected behavior
Srping Security should not create a session when configured to not create one.
Sample
I created a reproducer there:
https://github.com/obourgain/session-issue
Describe the bug
Spring Security, even if configured with
SessionCreationPolicy.NEVERorSessionCreationPolicy.STATELESScreates a session when using RequestHeaderAuthenticationFilter.It may be caused by the change here 4479cef#diff-b9376389ef77383ad282c387359020ed122ad52d641cf25de70f104deae213d8R113
that changed
AbstractPreAuthenticatedProcessingFilterto use aHttpSessionSecurityContextRepositoryby default, but fails to configure it properly withallowSessionCreation=falsewhen using aSessionCreationPolicythat should not create sessions.Also, when using
NEVERthe credentials may be read from the session (as expected) but with precedence over the headers sent in the request, which should be the source of truth.This may affect all subclasses of
AbstractPreAuthenticatedProcessingFilterand also other classes that started to useHttpSessionSecurityContextRepositoryby default in the commit mentionned above, but I didn't test this.To Reproduce
RequestHeaderAuthenticationFilterandSessionCreationPolicy.NEVERorSessionCreationPolicy.STATELESSin theSecurityFilterChain.SM_USERheader.Note that using MockMvc still creates the session, as we can see with a debugger, but doesn't seem to set the Set-Cookie header.
Expected behavior
Srping Security should not create a session when configured to not create one.
Sample
I created a reproducer there:
https://github.com/obourgain/session-issue