Grzegorz Borkowski (Migrated from SEC-1144) said:
I'm building the RESTful service with Spring Security and basic authentication. REST requires services to be stateless, so I set
(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.
Luke Taylor said:
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.
Grzegorz Borkowski said:
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.
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.
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.
Yes, it's in the current trunk. See SEC-1039.