Spring security’s SecurityContextHolder: session or request bound?

It depends on how you configured it (or lets say, you can configure a different behaviour).

In a Web application you will use the ThreadLocalSecurityContextHolderStrategy which interacts with SecurityContextPersistenceFilter.

The Java Doc of SecurityContextPersistenceFilter starts with:

Populates the {@link
SecurityContextHolder} with
information obtained from the
configured {@link
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 {@link
HttpSessionSecurityContextRepository}.
See this class for information
HttpSession related
configuration options.

Btw: HttpSessionSecurityContextRepository is the only implementation of SecurityContextRepository (I have found in the default libs)

It works like this:

• The HttpSessionSecurityContextRepository uses the httpSession (Key=”SPRING_SECURITY_CONTEXT”) to store an SecurityContext Object.
• The SecurityContextPersistenceFilter is an filter that uses an SecurityContextRepository for example the HttpSessionSecurityContextRepository to load and store SecurityContext Objects. If an HttpRequest passes the filter, the filter get the SecurityContext from the repository and put it in the SecurityContextHolder (SecurityContextHolder#setContext)
• The SecurityContextHolder has two methods setContext and getContext. Both uses a SecurityContextHolderStrategy to specify what exactly is done in the set- and get-Context methods. – For example the ThreadLocalSecurityContextHolderStrategy uses a thread local to store the context.

So in summary: The user principal (element of SecurityContext) is stored in the HTTP Session. And for each request it is put in a thread local from where you access it.