Spring Security
  1. Spring Security
  2. SEC-1082

SecurityContextHolderAwareRequestWrapper do not expose anonymous user.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.0.0 M1
    • Component/s: Core
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          Luke Taylor added a comment -

          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.

          Show
          Luke Taylor added a comment - 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.
          Hide
          Marcin Muras added a comment -

          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)

          Show
          Marcin Muras added a comment - 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)
          Hide
          Luke Taylor added a comment -

          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.

          Show
          Luke Taylor added a comment - 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.
          Hide
          Marcin Muras added a comment -

          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 ?

          Show
          Marcin Muras added a comment - 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 ?
          Hide
          Luke Taylor added a comment -

          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.

          Show
          Luke Taylor added a comment - 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.
          Hide
          Marcin Muras added a comment -

          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 ?

          Show
          Marcin Muras added a comment - 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 ?
          Hide
          Luke Taylor added a comment -

          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.

          Show
          Luke Taylor added a comment - 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.

            People

            • Assignee:
              Luke Taylor
              Reporter:
              marcin muras
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: