SEC-1082: SecurityContextHolderAwareRequestWrapper do not expose anonymous user.

[spring-projects-issues]

marcin muras(Migrated from SEC-1082) said:

SecurityContextHolderAwareRequestWrapper do not expose Authentication if user was anonymous (see getAuthentication() method).
It is fine but for example while using with webflow it is not so good. Webflow expose request principal (request.getPrincipal()) as “currentUser”. It means we will never have currentUser set if it was anonymous.

It may be good to add some property to SecurityContextHolderAwareRequestWrapper class to tell that we want to expose anonymous user.

[spring-projects-issues]

Luke Taylor said:

Please can you explain the requirement here? If you can give a detailed example of what you’re trying to do and explain why it’s not currently possible, that would be very useful.

[spring-projects-issues]

Marcin Muras said:

Hi. Please look at SecurityContextHolderAwareRequestWrapper.getAuthentication():
private Authentication getAuthentication()
{
Authentication auth = SecurityContextHolder.getContext().getAuthentication();
if(!authenticationTrustResolver.isAnonymous(auth))
return auth;
else
return null;
}
When user is logged anonymously it will not be exposed to HttpServletRequest.

Whats more in Spring Webflow we can get logged user in EL by invoking “currentUser” expression.
This “currentUser” expression uses SS HttpServletRequestWrapper to get user. It means that we never
get anonymously user in Webflow.

I wrote CustomSavedRequestAwareWrapper to expose also anonymous user. (see attachement)

[spring-projects-issues]

Luke Taylor said:

I’m still not clear what the requirement is. This wrapper is intended to mimic the servlet API and, as I’ve explained in other issues, there is no concept of an “anonymously authenticated” user in standard servlet security. The standard servlet methods should therefore return null if nobody is authenticated.

[spring-projects-issues]

Marcin Muras said:

Yes exactly this wrapper mimic servlet API. And Spring Webflow use Servlet API to access logged user as “currentUser”. So webflow never access anonymous user.
My proposal was to add some switcher and enable to exposing anonymous user to servlet API. But now I think that it may be stupid and not consistent with specification.
What do you think ?

[spring-projects-issues]

Luke Taylor said:

I still don't see why there would be an expectation that accessing the "currentUser" in webflow when there is nobody authenticated should return something other than null. If it is being used without Spring Security (with normal container authentication) then the servlet API would return null. Likewise if Spring Security is being used without an AnonymousProcessingFilter. An application based on the servlet API shouldn't be assuming that Spring Security is in use.

[spring-projects-issues]

Marcin Muras said:

Yes all what you said is true.

But lets talk about case when you use Servlet API with Spring Security AND AnonymousProcessingFilter.
In this case it looks like you expects something else what serlvet API offers. You have been authenticated (ok it was only anonymous authentication but it doesn't matters). User may expects that they receive something else than null (because they was authenticated but using only different method - anonymous).

Summary:
From servlet API point of view specification says that servlet methods should return null if nobody is authenticated.
But from Spring Security point of view someone was authenticated (they use only different method to do that - anonymous method).

It think that the question here is:
If we should expose anonymously authenticated user to servlet API or not ?

[spring-projects-issues]

Luke Taylor said:

The point of the servlet API is that it is independent of Spring Security and has standard documented behaviour. Existing applications may depend on that behaviour so we are unlikely to change it. If an application knows that it is using Spring Security, then it can use Spring Security APIs to access the security context. The use of an AnonymousProcessingFilter does not mean that "someone was authenticated" from Spring Security's point of view. Any unauthenticated access will be represented by an anonymous token in the security context. The reason this was originally introduced was to simplify the configuration of access controls in the security application context. If you read the chapter in the reference manual it explains this.