Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1968: PreAuthenticatedProcessingFilter does not clear out the security context causing user to unintentionally remain authenticated #2192

spring-issuemaster opened this Issue May 30, 2012 · 2 comments


None yet
2 participants

Matt Wheeler (Migrated from SEC-1968) said:

When the pre-authenticated user is null, the previously authenticated user's security context remains, and as such, the previous user remains authenticated.

It seems like the AbstractPreAuthenticatedProcessingFilter should clear out the security context in doAuthenticate if the principal is null. I can override the getPreAuthenticatedPrincipal call to do this (if I return null for the principal), but it seems that this is not something the user should have to manage. And, it seems like a side-effect / hack to put something like that in a method that should just be getting the principal, and doAuthenticate itself is private. This is dangerous because later in the chain, in AbstractSecurityInterceptor.beforeInvocation(Object object) the security context is not null, even though it should be, and so, no exception is thrown from:

    if (SecurityContextHolder.getContext().getAuthentication() == null) {
                "An Authentication object was not found in the SecurityContext"), object, attributes);

It could also possibly be argued that the security context should be cleared in AbstractPreAuthenticatedFilter.requiresAuthentication in the session invalidation on a principal change - namely in here:

    if (invalidateSessionOnPrincipalChange) {
        HttpSession session = request.getSession(false);

        if (session != null) {
            logger.debug("Invalidating existing session");

I have attached a test application that demonstrates this in the simplest format I could come up with. Basically the pre-authentication occurs by grabbing a username from a request parameter, and then it displays the logged in user's username on the home page.

So if I go to http://localhost:8080/security/?username=bob the application will display 'Hello bob'. If I hit http://localhost:8080/security/?username=jimi, it will switch to saying 'Hello jimi', but if I do http://localhost:8080/security/?username= it will remain at 'Hello jimi' (or whatever the previously authenticated user was), instead of requiring authentication.

However, if in getPreAuthenticatedPrincipal() I call SecurityContextHolder.clearContext(), then hitting http://localhost:8080/security/?username= will result in taking me to the login page which I think is the desired behavior if the user is not pre-authenticated - indicated by getPreAuthenticatedPrincipal() returning null.

Rob Winch said:

@matt - Thank you for your report and especially the detailed instructions on reproducing the issue. I believe you are correct that this is a bug and needs resolved.

Matt Wheeler said:

No problem. Thank you for the great product.

@spring-issuemaster spring-issuemaster added this to the 3.1.1 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment