Can SecurityContextHolder Shared across users

Question

In response to this question securitycontextholder-session-or-request-bound. I was implementing CustomAuthenticationManager using this example how-to-customAuthenticationManager. It turns out, my user experience get Accross Session.

For example, User A interacts with web App, sometimes when accessing profile, User A could get User B Profile(this because the app is retrieving UserProfileLoggedIn from SecurityContextHolder's principal and accessing database) and at the same time User B was logged on, but probably not accessing profile.

I wonder is this a SecurityContextHolder leakage ? I know that SecurityContextHolder is just a way of implement HttpSession as a container to contain userDetails and so on.

Now, after having the problems, I'm changing the customAuthenticationManager to customAuthenticationProvider. For additional information, the users is around 100-500 concurrent users at mid day.

For additional information, I'm implementing SecurityContextHolder in my @Service Class, so another team member can get easily

@Service
public MyServiceImpl implement MyServiceInterface{
    public UserDetail findUser(){
       return (UserDetail) SecurityContextHolder.getContext().
              getAuthentication().getPrincipal();
     }
}

After struggling for hours, and implement singleton-styled to obtain SecurityContextHolder from Controller and pass to Service, I still having issue with SecurityContextHolder leakage. I still have no Idea what could be the problem...... — wahyuagungs, Jan 21 '16 at 08:44

score 2 · Accepted Answer · answered Jan 20 '16 at 15:15

2

By default, the implementation of SecurityContextHolder is bound to an instance of ThreadLocal:

It is scalable as much as your container provides simultaneous threads to Spring Security.
The abstraction is not an implementation of HttpSession; however, it provides integration with the underlying HTTP Servlet provider to transfer HTTP security information to the application layer managed by Spring.
The composition over ThreadLocal enables the user of API to be able take advantage of working with multiple views of data in different threads. That's also why if you have proper thread configurations in your HTTP container, you should not have a scalability issue in terms of number of users.

answered Jan 20 '16 at 15:15

nobeh

9,784
10
49
66

Can you analyze what could be the problem in my case? is it because I'm not implementing "ThreadLocal" in my customAuthenticationManger due to override the Standard ProviderManager Or because I'm make my way to get SecurityContextHolder from my @Service. Additional Info in my question... – wahyuagungs Jan 20 '16 at 15:21
Can you please further update your question with bits of how you use the Service layer in your Controller? And, are you sure that you fetch the right information from DAO layer? – nobeh Jan 20 '16 at 15:27
As you can see, I've updated my question. I'm using "@Service" to contain SecurityContextHolder in one place so other component can use it without having to intialize the same code. I wonder is it because this implementation? Or is it because my implementation if CustomAuthenticationManager??? If it because my "@Service" implementation, is it safe to use static method instead "@Service" ? – wahyuagungs Jan 20 '16 at 15:32
First impression is that you need to use `SecurityContextHolder` from your Controller layer instead of Service. Simple reason is that you cannot guarantee that both Controller and Service layer run in the same thread. – nobeh Jan 20 '16 at 15:39
That's what I'm talking about........ But, if I'm trying to getUserDetails both from myService and myController, is it safe to use Static Method instead ? Because if I have to Call getPrincipal in each of myControllers.... what a waste .... – wahyuagungs Jan 20 '16 at 15:42
The proper way to do this: (1) load `UserDetails` from Controller layer (2) Pass in `UserDetails` to the Service layer to do the rest. This is not a good practice to obtain the *same* information from multiple layers in different places. Hope this helps. – nobeh Jan 20 '16 at 15:43
This problems, only occurred today (only 2 days after being deployed)... I'm recently change all my code to singleton-styled for my SecurityContextHolder, although the damage has been done-and there is nothing I can do about it.... Perhaps I have to do it if there is no solution achieved – wahyuagungs Jan 20 '16 at 15:49

score 1 · Answer 2 · answered Jan 21 '16 at 12:16

I've finally found the fundamental problem inside my code. One of my team member, was putting a variable inside @Service Class... like this....

@Service 
public AnotherServiceImpl implements AnotherService{

  UserDetail userdetail;  //This is hillarious

  @Autowired
  MyServiceImpl myService;

  @Override
  public .......

   //......
}

And obviously I did not see that coming..... After delete "UserDetail" variable, everything come back as it was supposed to be.. Thanks, I hope someone can learn from my "stupid" mistake

Can SecurityContextHolder Shared across users

2 Answers2