9

In SpringSecurity it has a class name SecurityContextHolder and its spec: 'Associates a given SecurityContext with the current execution thread.' With web application whenever a request comes to server then Spring also reload and set SecurityContext of that request in SecurityContextHolder for its thread?

Peter Mularien
  • 2,578
  • 1
  • 25
  • 34
Martin
  • 101
  • 2
  • 3
  • Please see http://stackoverflow.com/questions/6408007/spring-securitys-securitycontextholder-session-or-request-bound – Ritesh Aug 26 '11 at 12:59

2 Answers2

9

Yes, the SecurityContextPersistenceFilter takes care of this. By default it locates the SecurityContext in the HttpSession and binds it to the thread via the SecurityContextHolder. When the request is finished processing it does the reverse - it takes the SecurityContext from the thread and puts it in the session.

From the Javadoc:

Populates the SecurityContextHolder with information obtained from the configured SecurityContextRepository prior to the request and stores it back in the repository once the request has completed and clearing the context holder. By default it uses an HttpSessionSecurityContextRepository.

sourcedelica
  • 23,940
  • 7
  • 66
  • 74
  • Shouldn't that make it also thread safe? It seems that the `SecurityContext` is not being shared across threads in my application ([link](http://stackoverflow.com/questions/34273755/why-is-the-authentication-object-of-the-securitycontext-not-shared-across-thread)). – Stefan Falk Jun 09 '16 at 19:02
7

With web application whenever a request comes to server then Spring also reload and set SecurityContext of that request in SecurityContextHolder for its thread?

Basically yes.

The default behavior of SecurityContextHolder.getInstance() is to return a SecurityContextHolder instance that it stored as a thread-local of the current thread. (This is only the default mechanism. You can use a different strategy for locating the SecurityContextHolder by calling SecurityContextHolder.setStrategemName())

A SpringSecurity filters ensure that the request's SecurityContextHolder (however it is located) is loaded with the request credentials at the start and that the holder is cleared at the end of request processing.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • Elaborating, the key is that the filter looks in the remote invocation attributes for the security context. Only if a security context is in the remote invocation attributes can it be set in the SecurityContextHolder. This security context is typically supplied from the client with a similar filter that processes the outgoing invocation and places the security context from the thread local into the remote invocation. – Zach Aug 25 '11 at 21:08
  • [Why is this not working](https://github.com/spring-projects/spring-security/issues/3919) for me? See [stackoverflow question](http://stackoverflow.com/questions/34273755/why-is-the-authentication-object-of-the-securitycontext-not-shared-across-thread). – Stefan Falk Jun 12 '16 at 10:51