I don't understand one thing. If for example 5 users are logging into your application so spring security creates 5 different context ? I'm little confused about contexts in spring.
All components in spring are Singleton (by default). So if I create one component and two different authenticated users are working on this component so they are working on the same data ?
SecurityContext is kept in SecurityContextHolder with thread local strategy by default. Which means that SecurityContext will be scoped to a thread.
In Spring MVC application each request runs in its own thread. And Spring Security (SecurityContextPersistenceFilter in particular) populates the SecurityContextHolder with SecurityContext found in the HTTP Session (if one already exist).
So if five users are logged in your application, five security contexts will exist but only the one belonging to the user making the request will be available from the thread handling the request.
And for the second part of your question, yes, multiple users will be working with the same instances of your singleton scoped beans. But I'm not sure that is a problem. Your singleton beans may be services, DAOs, etc. and you probably don't store a state on those which can be directly changed by the users.
Hopefully this brief and simplified post explained it, if not leave a comment and I'll add more details.
More information:
SecurityContextPersistenceFilter JavaDoc
Related
I would want organize multithreaded access via the rest api to a resource using Spring Boot.
There is information (I found it here) that SrpingBoot can parallelize requests (which I doubt) to the controller with scope-singlotone.
How to start the design of such a controller, or what approach to apply for this?
Spring handles requests in parallel - that means your singleton controllers have to be thread-safe.
If you have a single resource which cannot handle parallel access you have to use Java's synchronized or locks to serialize the access.
Spring Rest Controllers do handle request using a thread pool. Since Spring beans are singleton, your Spring Beans should be Stateless or we can say bean should have a sheared state. Which means you cannot have a state that will change with the time.
I have a vanilla Spring Boot application that consists of a controller, a service and a DAO layer. The controller code calls the service code and so on.
To implement some semblance of security, I am currently using Spring Security 4.0.x's global method security annotations in combination with Spring Security ACL to lock down my service methods.
Requests that go through my controllers are auth-ed and authorized just fine because a principal / user is in context. HOWEVER, I also have some additional non-user facing code that listens for messages from an AWS queue. Within this listener code I invoke some secured services (to stay DRY and not duplicate business logic) but for this situation no user is in scope.
Generally speaking:
For a situation like the one I'm describing, what is a good / acceptable way to authenticate user-less method invocations e.g. ones that don't come through an HTTP request (or to bypass the check)? I am considering manually setting the SecurityContextHolder with a "system user" in my message listener code but this has some code smell.
Is method level security better applied at the controller level?
I'm working on a prototype that initiates Spring Batch jobs from web requests. The jobs consist of a series of Tasklets, and I'd like the Tasklets to have some of their members auto-wired in with a session scope.
I'd also like to be able to use the role of the user who initiated the request in Spring Security if possible.
Is there a sensible way to do this?
In my spring MVC application i want to access Principal object created by spring security in my service layer. I thought about injecting it in my service classes, but I am sure it will not be thread safe.
Other option I am thinking, is to pass it to all service methods as argument but this do not look very clean to me.
What would be the better way to do this?
I think that the best approach would be to use the SecurityContextHolder.
Principal principal = SecurityContextHolder.getContext().getAuthentication();
Spring explains how it works in the documentation:
The most fundamental object is SecurityContextHolder. This is where we
store details of the present security context of the application,
which includes details of the principal currently using the
application. By default the SecurityContextHolder uses a ThreadLocal
to store these details, which means that the security context is
always available to methods in the same thread of execution, even if
the security context is not explicitly passed around as an argument to
those methods. Using a ThreadLocal in this way is quite safe if care
is taken to clear the thread after the present principal's request is
processed. Of course, Spring Security takes care of this for you
automatically so there is no need to worry about it.
Since it uses a ThreadLocal to store the current authentication, you will not have any thread safety problem.
How would we implement a Session Facade design pattern in the Spring application? Would the role of the Session facade be simply served by the service bean class that would be annotated for the transactions and will have a session scope?
A Spring service (with singleton scope) is like a local stateless session bean, it is an implementation of the Session Facade pattern, only for applications that are not distributed. Spring does make the case that in most cases services don't need to be distributed and that the distributed aspects of Session facade are not as all-pervasive as J2EE made them out to be.
(When you say "session scope" it sounds like you're confusing session as in transactional with session as in HttpSession, because Spring uses the term session scope to refer to HttpSessions. (At least it's confusing me about what's intended.) My reading of the Session facade description leads me to think it doesn't have anything to do with an HttpSession.)
Anyway, I'd say the basic goal of encapsulating complexity is still valid. In some cases the goal of giving distributed access is still very valid, it's just not the default case like J2EE tried to make it out to be. And Seam makes a case for stateful session beans still being relevant.
Session should be associated with the web tier, not services.
Services do indeed own transactions, so they should have that annotation.