SEC-3099: ChangeSessionIdAuthenticationStrategy seems to be swallowing an exception resulting in null authentication in security context holder

Stephen Morrison (Migrated from SEC-3099) said:

Hi folks,
Upon upgrading from 3.2.6.RELEASE -> 3.2.7.RELEASE I'm no longer able to authenticate successfully with my web application. (I'm using Spring Boot:
"org.springframework.boot:spring-boot-starter-security:1.2.2.RELEASE" -> "org.springframework.boot:spring-boot-starter-security:1.2.5.RELEASE")
The Java Config of Spring Security remains unchanged during the upgrade. It appears the ChangeSessionIdAuthenticationStrategy is throwing an exception preventing the CompositeSessionAuthenticationStrategy iterating through it's delegates.

With 3.2.7.RELEASE DEBUG logging:
{{2015-09-02 09:24:29.296 DEBUG 8387 --- [nio-8020-exec-7] w.a.UsernamePasswordAuthenticationFilter : Request is to process authentication
2015-09-02 09:24:29.296 DEBUG 8387 --- [nio-8020-exec-7] o.s.s.authentication.ProviderManager : Authentication attempt using c.x.y.user.CustomAuthenticationProvider
2015-09-02 09:24:29.311 DEBUG 8387 --- [nio-8020-exec-7] s.CompositeSessionAuthenticationStrategy : Delegating to org.springframework.security.web.authentication.session.ChangeSessionIdAuthenticationStrategy@162277b2
2015-09-02 09:24:29.322 DEBUG 8387 --- [nio-8020-exec-7] w.c.HttpSessionSecurityContextRepository : SecurityContext is empty or contents are anonymous - context will not be stored in HttpSession.
2015-09-02 09:24:29.322 DEBUG 8387 --- [nio-8020-exec-7] s.s.w.c.SecurityContextPersistenceFilter : SecurityContextHolder now cleared, as request processing completed}}

With 3.2.6.RELEASE DEBUG logging:
{{2015-09-02 09:32:49.958 DEBUG 8464 --- [nio-8020-exec-3] w.a.UsernamePasswordAuthenticationFilter : Request is to process authentication
2015-09-02 09:32:49.959 DEBUG 8464 --- [nio-8020-exec-3] o.s.s.authentication.ProviderManager : Authentication attempt using c.x.y.user.CustomAuthenticationProvider
2015-09-02 09:32:49.977 DEBUG 8464 --- [nio-8020-exec-3] s.CompositeSessionAuthenticationStrategy : Delegating to org.springframework.security.web.authentication.session.ChangeSessionIdAuthenticationStrategy@4eaed7fc
2015-09-02 09:32:49.977 DEBUG 8464 --- [nio-8020-exec-3] s.CompositeSessionAuthenticationStrategy : Delegating to org.springframework.security.web.csrf.CsrfAuthenticationStrategy@1d4fb508
2015-09-02 09:32:49.978 DEBUG 8464 --- [nio-8020-exec-3] w.a.UsernamePasswordAuthenticationFilter : Authentication success. Updating SecurityContextHolder to contain: org.springframework.security.authentication.UsernamePasswordAuthenticationToken@bbe6c99a: Principal: stephen:Stephen Morrison; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@fffbcba8: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: EFCFC307691D74540F49F99251099C3C; Granted Authorities: Role [id=1], Group [id=1], Role [id=2], Role [id=3], ROLE_USER}}

The Java Config for this web app is as follows:
{{
http
.authenticationProvider(authenticationProvider)
.authenticationProvider(rememberMeAuthenticationProvider())
.antMatcher("/admin/**")
.authorizeRequests().anyRequest().hasAuthority(Role.USER_ADMIN)
.and()
.formLogin()
.loginPage(login)
.permitAll()
.defaultSuccessUrl(home)
.and()
.logout().logoutUrl(logout)
.permitAll()
.and()
.rememberMe()
.rememberMeServices(rememberMeServices(userDetailsService));

        http.headers().frameOptions().disable();
        http.exceptionHandling().accessDeniedPage("/access-denied");

}}

The only ticket that smelled like it could have had an impact as part of 3.2.7.RELEASE was: https://jira.spring.io/browse/SEC-2913 but perhaps I am missing some session fixation related config from my Java Config?

Cheers,
Stephen

Start with ChangeSessionIdAuthenticationStrategy and CompositeSessionAuthenticationStrategy, comparing the 3.2.6 and 3.2.7 behavior described in the DEBUG logs. Reproduce the upgrade with the supplied Java Config and authentication provider, then trace the swallowed exception; done means the cause is identified and authentication updates the SecurityContextHolder as in the successful log.