Johannes Nicolai (Migrated from SEC-1797) said:
When AbstractPreAuthenticatedProcessingFilter invalidates a session after it detected a principal change, it does not create a new session which prevents the new security context from being stored (for a longer explanation why, look at http://forum.springsource.org/showthread.php?113171-Improper-use-of-SessionFixationProtectionStrategy-in-SessionManagementFilter).
AbstractPreAuthenticatedProcessingFilter should probably recreate the session after invalidating it when the principal changes. This will not trick developers new to Spring Security to come up with workarounds (like turning off session invalidation at principal change) that would currently enable a session fixation attack (since the session fixation protection strategy plugged into the default session management filter would not be called under these circumstances).
Johannes Nicolai said:
The only issue I currently see is how the default session management filter reacts on this. Wouldn't it call the session fixation protection strategy then and migrate the empty session to yet another new session?
Luke Taylor said:
It shouldn't, since it is only intended to detect newly authenticated users, not a change in the authentication. This is a bit of a special case, since most applications don't allow a user to authenticate within a session which is already authenticated with a different user. The original user would normally be expected to logout or close their browser when they were finished.