programmatic authentication switches users identities

[jtowell]

We have seen the *scary* scenario happen a couple times when testing our application. Please let me know how this could possibly be happening.

1) User 1 is logged in.
2) User 2 logs in (password has expired) forcing a change password. After which we programmatically authenticate user 2.
3) After this programmatic authentication user1 (still logged in) now becomes user 2!!

We are programmatically authenticating like this.

1) after change password

 UsernamePasswordAuthenticationToken result = new UsernamePasswordAuthenticationToken(user.getUsernameLookup(), password, user.getAuthorities());
Authentication authentication = authenticationManager.authenticate(result);

if(authentication.getPrincipal() instanceof User) {
    SecurityContextHolder.getContext().setAuthentication(authentication);
}

2) And then this in the controller after the prog authentication

 request.getSession().setAttribute(HttpSessionContextIntegrationFilter.SPRING_SECURITY_CONTEXT_KEY, SecurityContextHolder.getContext());

[wwheeler]

Which SecurityContextHolder strategy are you using? MODE_THREADLOCAL, or something else? Though I suspect it's unlikely that you're using MODE_GLOBAL, that could explain the behavior: normally your requests would be semi-isolated from one another (nothing enforcing that, but just as a matter of fact), so the transfer of the SecurityContext from the session to the GlobalSecurityContextHolderStrategy and back to the session (via the HttpSessionContextIntegrationFilter) would be unproblematic. But if two simultaneous requests occur, then you could get the following race:

1. User 1 makes a request, which runs up to but not including the point where the filter grabs the SecurityContext from the GlobalSecurityContextHolderStrategy. (This happens toward the end of the request when the HttpSessoinContextIntegrationFilter wants to transfer the SecurityContext from the request thread to the session so that the request thread can service another user.)
2. There's a context switch to user 2's request thread.
3. User 2's request starts and completes, and inside the GlobalSecurityContextHolderStrategy, user 1's SecurityContext is replaced with User 2's.
4. Context switch back to user 1's request thread.
5. User 1 grabs user 2's SecurityContext from the GlobalSecurityContextHolderStrategy and then the filter writes it out to the session.

Like I said I doubt you're using MODE_GLOBAL, but if you are, then that might be what's happening.

[Luke Taylor]

Or perhaps both users are logging in from the same browser process. In any case, it's almost impossible to determine what's going on unless you give a detailed description of what you're doing, do some debugging of browser requests and analyse the logs (and posting what you find).

[jtowell]

I am not setting the SecurityContextHolder strategy specifically so I assume the default is Thread Local. Thats what it looks to be from doc.

I was hoping someone had seen something similar which is why I was posting. It is a scary enough scenario to make me switch how we are authenticating on this specific scenario. I moved from a programmatic method as shown above to one in which we redirect to /j_acegi_security_check and authenticate almost exactly as we do on a normal login.

We haven't seen this again since our change in authentication strategy, although we are still very wary that this could possibly happen in the first place.