security-web: possible reauthentication & session invalidation for same principal?

[mellster]

org/springframework/security/web/authentication/preauth/AbstractPreAuthenticatedProcessingFilter.java:

The check !currentUser.getName().equals(principal) does not seem right as it is comparing a String to an Object, so principal change will be indicated and acted upon for any returned principal Object other than a String that equals currentUser.getName().

    private boolean requiresAuthentication(HttpServletRequest request) {
        Authentication currentUser = SecurityContextHolder.getContext().getAuthentication();

        if (currentUser == null) {
            return true;
        }

        Object principal = getPreAuthenticatedPrincipal(request);
        if (checkForPrincipalChanges &&
                !currentUser.getName().equals(principal)) {
            logger.debug("Pre-authenticated principal has changed to " + principal + " and will be reauthenticated");

TIA!

[Luke Taylor]

This is the documented behaviour if you enable that feature by setting checkForPrincipalChanges.

In the most common scenario, the pre-authenticated principal will be a String, but the principal in the Authentication will be a more complex object (typically a UserDetails instance). So comparing them directly isn't an option.

[mellster]

Thanks for getting back quickly - it does not seem right that you assume that the pre-authenticated principal is a String - switching the equals check so that you have !principal.equals(currentUser) would give the principal object the ability to check against a known interface (Authentication). But if this is documented behavior, my follow-up question is if it would be prudent to check if the session is already invalid as the constant reauthentication causes intermittent IllegalStateException if the session has already been invalidated. Also, is turning off checkForPrincipalChanges a potential security problem, or what are possible implications for this? Thanks!

[Luke Taylor]

Thanks for getting back quickly - it does not seem right that you assume that the pre-authenticated principal is a String - switching the equals check so that you have !principal.equals(currentUser) would give the principal object the ability to check against a known interface (Authentication).

The principal object is most commonly a String (a request header, or the remote user information pulled from an HttpRequest), so this would not be very useful in practice.

But if this is documented behavior, my follow-up question is if it would be prudent to check if the session is already invalid as the constant reauthentication causes intermittent IllegalStateException if the session has already been invalidated.

This would imply some sort of race condition where you are sending multiple simultaneous requests as the new user.

Also, is turning off checkForPrincipalChanges a potential security problem, or what are possible implications for this? Thanks!

It depends on your system. In most systems you wouldn't have a user changing during a session. The situation is exactly the same as if someone takes over an existing session without any pre-authentication system in place. Normally a user would be expected to close their browser to kill the session if they are using a public browser.