Describe the bug Spring Security uses RequestAttributeSecurityContextRepository instead of the NullSecurityContextRepository for Stateless sessions.

To Reproduce Run the program with minimal configuration:

@Configuration
class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http, UserDetailsService userDetailsService) throws Exception {
        http.authorizeHttpRequests(requests -> requests
                .anyRequest().authenticated()
        );
        http.userDetailsService(userDetailsService);
        http.httpBasic(Customizer.withDefaults());
        http.sessionManagement(sessionConfig -> sessionConfig.sessionCreationPolicy(SessionCreationPolicy.STATELESS));
        http.csrf(csrfCustomizer -> csrfCustomizer.disable());
        return http.build();
    }

    @Bean
    UserDetailsService userDetailsService() {
        InMemoryUserDetailsManager inMemoryUserDetailsManager = new InMemoryUserDetailsManager();
        inMemoryUserDetailsManager.createUser(
                User.builder().username("john").password("pass").roles("USER").build()
        );
        return inMemoryUserDetailsManager;
    }
}

Expected behavior According to the documentation, Spring should use NullSecurityContextRepository but RequestAttributeSecurityContextRepository is used instead

Sample There is a test in below repository that checks SecurityContextRepository used by BasicAuthenticationFilter

https://github.com/slawekludwiczak/spring-security-basic-repository

PS. maybe I don't understand something, but it is a bit weird for me that for Stateless sessions there is SessionManagementFilter registered

Comment From: sjohnr

@slawekludwiczak thanks for the report.

PS. maybe I don't understand something, but it is a bit weird for me that for Stateless sessions there is SessionManagementFilter registered

This is fairly understandable. There were a number of changes around and relating to session management in the 5.8 release in preparation for new defaults in 6.0.

First, each authentication filter is now configured with a SecurityContextRepository and is responsible for persisting the SecurityContext itself, making the SessionManagementFilter unnecessary.

Second, the behavior in 5.8 was to register SessionManagementFilter by default, with SessionCreationPolicy.STATELESS configuring things to avoid creating a session. In 6.x, a SessionManagementFilter is no longer registered by default. However, choosing SessionCreationPolicy.STATELESS does register one again.

Note that we actually do want to use RequestAttributeSecurityContextRepository even with stateless authentication, as this allows Spring Security to work with other dispatcher types within the same server request (such as a forward).

At this point, the documentation likely needs some updates to reflect the current realities. We could potentially use this ticket for that. In the meantime, I believe you can simply remove the http.sessionManagement(...) configuration since the BasicAuthenticationFilter is now configured for stateless authentication by default.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: marameref

Is this issue still open, I wish to work on it?

Comment From: sjohnr

Hi @marameref. Yes, it is still open and you are welcome to work on it! I am here to discuss with you how to move forward with updating the documentation, so let me know your thoughts/questions.