Spring Security
  1. Spring Security
  2. SEC-1144

Don't use HttpSessionContextIntegrationFilter when <http> element has create-session="never"

    Details

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

      Description

      I'm building the RESTful service with Spring Security and basic authentication. REST requires services to be stateless, so I set
      <http create-session="never">
      (default setting, ifRequired, seems buggy for me: the session is created at first request anyway, so it behaves exactly like "always").

      This configuration (create-session="never") works properly for me. But when I look at the stack trace, I'm frightened of amount of classes and method calls that Spring Security uses in this case. The HttpSessionContextIntegrationFilter seems to be the main culprit. What is it used for at all, if there is no session ever in this case? The best solution would be to throw away HttpSessionContextIntegrationFilter from the stack when create-session="never". It adds only complexity and processing overhead for completely no purpose.

        Activity

        Hide
        Luke Taylor added a comment -

        HttpSessionContextIntegrationFilter (or SecurityContextPersistenceFilter as it is now called) is essential as it clears the security context after a request. The processing overhead should be minimal.

        "ifRequired" should only create a session if the user was authenticated during the request. It isn't the same as "always", which creates a session up-front. How these settings map to bean properties is explained in the namespace appendix of the reference manual.

        Show
        Luke Taylor added a comment - HttpSessionContextIntegrationFilter (or SecurityContextPersistenceFilter as it is now called) is essential as it clears the security context after a request. The processing overhead should be minimal. "ifRequired" should only create a session if the user was authenticated during the request. It isn't the same as "always", which creates a session up-front. How these settings map to bean properties is explained in the namespace appendix of the reference manual.
        Hide
        Grzegorz Borkowski added a comment -

        I see.
        Perhaps the name of the filter is misleading. Also its javadoc says: "Populates the SecurityContextHolder with information obtained from the HttpSession." and doesn't mention (or I don't see) anything about clearing the context. So it's name and description suggests that in stateless application this filter is useless.
        Anyway, I thought the context is stored as request attribute, so it should be automatically cleared at request end. But now I looked at SecurityContextHolder javadoc, and it mentions some modes: thread local, system, global (too bad it doesn't say what they mean - how system mode works and what is it for?). I don't see request mode (strange why?). So in case of thread local, it must be really cleared, as you said.

        Show
        Grzegorz Borkowski added a comment - I see. Perhaps the name of the filter is misleading. Also its javadoc says: "Populates the SecurityContextHolder with information obtained from the HttpSession." and doesn't mention (or I don't see) anything about clearing the context. So it's name and description suggests that in stateless application this filter is useless. Anyway, I thought the context is stored as request attribute, so it should be automatically cleared at request end. But now I looked at SecurityContextHolder javadoc, and it mentions some modes: thread local, system, global (too bad it doesn't say what they mean - how system mode works and what is it for?). I don't see request mode (strange why?). So in case of thread local, it must be really cleared, as you said.
        Hide
        Luke Taylor added a comment -

        The naming is largely historical - it's main function is storage and retrieval of the SecurityContext, hence the name change to SecurityContextPersistenceFilter, which removes the assumption that the HttpSession will be sued. Clearing of the SecurityContextHolder is a subordinate (though essential) part of its job.

        The context isn't stored as a request attribute as it isn't just intended for web application use and may be required in parts of the application which are unaware that they are running in a web app (e.g. in the case of method security). The modes are just names that can be used to set a particular strategy by specifying it as a system property ("spring.security.strategy"). The names correspond to the implementations of SecurityContextHolderStrategy which are available out of the box. There's no "system" mode. Most people don't have any need to change the default behaviour.

        Show
        Luke Taylor added a comment - The naming is largely historical - it's main function is storage and retrieval of the SecurityContext, hence the name change to SecurityContextPersistenceFilter, which removes the assumption that the HttpSession will be sued. Clearing of the SecurityContextHolder is a subordinate (though essential) part of its job. The context isn't stored as a request attribute as it isn't just intended for web application use and may be required in parts of the application which are unaware that they are running in a web app (e.g. in the case of method security). The modes are just names that can be used to set a particular strategy by specifying it as a system property ("spring.security.strategy"). The names correspond to the implementations of SecurityContextHolderStrategy which are available out of the box. There's no "system" mode. Most people don't have any need to change the default behaviour.
        Hide
        Grzegorz Borkowski added a comment -

        Yes, my fault: it's not system mode, but system property. SecurityContextPersistenceFilter name sounds much better - I assume this name is changed in version 3.0.

        Show
        Grzegorz Borkowski added a comment - Yes, my fault: it's not system mode, but system property. SecurityContextPersistenceFilter name sounds much better - I assume this name is changed in version 3.0.
        Hide
        Luke Taylor added a comment -

        Yes, it's in the current trunk. See SEC-1039.

        Show
        Luke Taylor added a comment - Yes, it's in the current trunk. See SEC-1039 .

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Grzegorz Borkowski
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: