Hello, I'm not good at English, so please understand that the title is a bit vague.

When I use security, I often implement the attemptAuthentication method to try login with JSON request.

But this time, I found something unusual when using Security 6.1 in the Spring Boot 3.x version, not Security 5.7.

This code is the code used in 6.1

private final UserDetailsService userDetailsService;

    public SecurityConfig(final UserDetailsService userDetailsService) {
        this.userDetailsService = userDetailsService;
    }

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

        AuthenticationManagerBuilder sharedObject = http.getSharedObject(AuthenticationManagerBuilder.class);

        sharedObject.userDetailsService(this.userDetailsService);
        AuthenticationManager authenticationManager = sharedObject.build();

        http.authenticationManager(authenticationManager);

        http
            .csrf(AbstractHttpConfigurer::disable)
//            .formLogin(Customizer.withDefaults())
            .formLogin(AbstractHttpConfigurer::disable)
            .authorizeHttpRequests(authorizeRequest ->
                    authorizeRequest
                            .requestMatchers(
                                    antMatcher("/auth/**")
                            ).hasRole("MEMBER")
                            .requestMatchers(
                                    antMatcher("/h2-console/**")
                            ).permitAll()
                            .anyRequest().permitAll()
            )
            .addFilterAt(
                    this.abstractAuthenticationProcessingFilter(authenticationManager),
                    UsernamePasswordAuthenticationFilter.class)
            .headers(
                    headersConfigurer ->
                            headersConfigurer
                                    .frameOptions(
                                            HeadersConfigurer.FrameOptionsConfig::sameOrigin
                                    )
            );

        return http.build();
    }

    public AbstractAuthenticationProcessingFilter abstractAuthenticationProcessingFilter(final AuthenticationManager authenticationManager) {
        return new LoginAuthenticationFilter(
                "/api/login",
                authenticationManager
        );
    }

This code is the code used in 5.7

@Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

        AuthenticationManagerBuilder sharedObject = http.getSharedObject(AuthenticationManagerBuilder.class);

        sharedObject.userDetailsService(this.userDetailsService);
        AuthenticationManager authenticationManager = sharedObject.build();

        http.authenticationManager(authenticationManager);

        http
            .csrf(AbstractHttpConfigurer::disable)
//            .formLogin(Customizer.withDefaults())
            .formLogin(AbstractHttpConfigurer::disable)
            .authorizeHttpRequests(authorizeRequest ->
                    authorizeRequest.antMatchers("/auth/**")
                            .hasRole("MEMBER")
            )
            .addFilterAt(
                    this.abstractAuthenticationProcessingFilter(authenticationManager),
                    UsernamePasswordAuthenticationFilter.class)
            .headers(
                    headersConfigurer ->
                            headersConfigurer
                                    .frameOptions(
                                            HeadersConfigurer.FrameOptionsConfig::sameOrigin
                                    )
            );

        return http.build();
    }

If you set this up and send it as a JSON request like throwing a Rest API, the authentication token is normally registered in the SecurityContextHolder until version 5.7 is used.

This time, in 6.1, it was registered as AnonymousUser, so the normal result did not come out.

this result in 5.7

SecurityContextHolder.getContext().getAuthentication() = UsernamePasswordAuthenticationToken [Principal=com.example.oldestsecurity.domains.user.dto.AuthenticationDetail [Username=tester, Password=[PROTECTED], Enabled=true, AccountNonExpired=true, credentialsNonExpired=true, AccountNonLocked=true, Granted Authorities=[ROLE_MEMBER]], Credentials=[PROTECTED], Authenticated=true, Details=null, Granted Authorities=[ROLE_MEMBER]]

this result in 6.1

SecurityContextHolder.getContext().getAuthentication() = AnonymousAuthenticationToken [Principal=anonymousUser, Credentials=[PROTECTED], Authenticated=true, Details=WebAuthenticationDetails [RemoteIpAddress=0:0:0:0:0:0:0:1, SessionId=null], Granted Authorities=[ROLE_ANONYMOUS]]

I started looking at it this week, but I didn't have time to see much of the internal operation code, but the roughly confirmed ones are as follows

  1. Do not use CompositeSessionAuthenticationStrategy, an implementation class of SessionAuthenticationStrategy.

  2. The sessionAuthenticationStrategy method code of SessionManagementConfigurer has changed.

I just couldn't figure it out,

I'm not really sure if this result is your intention or a mistake while upgrading the version.

As I went up to version 6.1, I found out that h2 also had to add permission settings to access the h2 page, but I think these results mentioned above were intended.

So, come to the point. I wonder how I can make this authentication result come out normally.

Also, I wonder if some configuration code was changed to cause this to happen.

Comment From: keede7

Additionally, looking at it once, using NullAuthencationStrategy is the same, but it has been changed to using repository typ from SecurityContext to Supplier<SecurityContext>

Somewhere,, it seems that there is a section where the stored authentication token is deleted,, it is not easy

Comment From: keede7

Well, when I looked for it today, I couldn't use DelegatingSecurityContextRepository, which is used when SecurityContextRepository is the default automatic setting.

Use only RequestAttributeSecurityContextRepository, which is the initial configuration implementation of AbstractAuthenticationProcessingFilter, I confirmed that there is

I think it was because I registered a new authentication filter.

So I just ended up using the DelegatingSecurityContextRepository constructor for my new filter.

In the current situation, it seems that there is no need for other comments.