Depende de cómo lo haya configurado (o, por ejemplo, puede configurar un comportamiento diferente).
En una aplicación web usará ThreadLocalSecurityContextHolderStrategy
que interactúa con SecurityContextPersistenceFilter
.
El Java Doc de SecurityContextPersistenceFilter
comienza con:
rellena la {@ link} SecurityContextHolder con información obtenida del configurado {@ link SecurityContextRepository} antes de la la solicitud y lo almacena en la espalda el repositorio una vez completada la solicitud y borrar el contexto titular. De forma predeterminada, usa un {@link HttpSessionSecurityContextRepository}. Consulte esta clase para obtener información HttpSession relacionada con opciones de configuración.
BTW: HttpSessionSecurityContextRepository es la única aplicación de SecurityContextRepository (He encontrado en las librerías por defecto)
Funciona así:
- El
HttpSessionSecurityContextRepository
utiliza el HttpSession (= clave" SPRING_SECURITY_CONTEXT ") para almacenar un objeto SecurityContext
.
- El
SecurityContextPersistenceFilter
es un filtro que usa un SecurityContextRepository
por ejemplo HttpSessionSecurityContextRepository
para cargar y almacenar objetos SecurityContext
. Si un HttpRequest pasa el filtro, el filtro de conseguir la SecurityContext
desde el repositorio y lo puso en la SecurityContextHolder (SecurityContextHolder#setContext
)
- El
SecurityContextHolder
tiene dos métodos setContext
y getContext
. Ambos usan un SecurityContextHolderStrategy
para especificar qué se hace exactamente en los métodos set y get-Context. - Por ejemplo, el ThreadLocalSecurityContextHolderStrategy
usa un hilo local para almacenar el contexto.
En resumen: El usuario principal (elemento de SecurityContext) se almacena en la sesión HTTP. Y para cada solicitud, se coloca en un hilo local desde donde se accede.