I have a J2EE REST-based web application that uses Spring Security 4.0.1.RELEASE. I am configuring Spring Security with a Java-based configuration and have set the session creation policy to STATELESS like so:
@Configuration
@EnableWebSecurity
@EnableGlobalMethodSecurity(secureEnabled=true, prePostEnabled=true, jsr250Enabled=true, order=1)
public class DefaultSecurityBeansConfig extends WebSecurityConfigurerAdapter {
// ...
@Override
protected void configure(HttpSecurity http) throws Exception {
http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS).and()...; // additional config omitted for brevity
// ...
}
// ...
}
After reading this article about Spring Security session management, I believe that the SessionManagementFilter
filter should not be running in Spring Security's filter chain. But it definitely is. I can set a breakpoint in that class's doFilter
method, and it is run on every request to the server.
What is going on here? The fact that this filter is running is causing other unexpected behavior in my app that I thought had been configured away.
Thanks.
When using Spring Security, session management is broader than storing the authenticated user in the session (as explained in the Session Management Section of the Spring Security Guide).
HTTP session related functionality is handled by a combination of the
SessionManagementFilter
and theSessionAuthenticationStrategy
interface, which the filter delegates to. Typical usage includes session-fixation protection attack prevention, detection of session timeouts and restrictions on how many sessions an authenticated user may have open concurrently.
Saying sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
doesn't mean that your application is stateless, it means that Spring Security won't create a session. If there is something else in your application still creating a session, Spring Security will try to protect it from a session-fixation attack.
How a session-fixation attack is done depends on the configured strategy; the default is to change the session identifier on each request. In Servlet 3.1 and newer containers, the ChangeSessionIdAuthenticationStrategy
is the default if no explicit configuration is done. In Servlet 3.0 and below, the default is migrateSession
.
You can disable session-fixation protection by doing sessionFixation().none()
; however, you have to question if that is what you really want as that, potentially, makes your application less safe.
Depending on what breaks/fails you might want to fix that instead of making your application less secure.