Spring Spring SecurityContextHolder: ¿sesión o solicitud vinculada?

¿El UserPrincipal que recupero de SecurityContextHolder vinculado a las solicitudes o a las sesiones?

UserPrincipal principal = (UserPrincipal) SecurityContextHolder.getContext().getAuthentication().getPrincipal();

Esta es la forma en que accedo al usuario actualmente conectado. ¿Esto invalidará si se destruye la sesión actual?

Depende de cómo lo haya configurado (o, por ejemplo, puede configurar un comportamiento diferente).

En una aplicación web, utilizará ThreadLocalSecurityContextHolderStrategy que interactúa con SecurityContextPersistenceFilter .

El Java Doc de SecurityContextPersistenceFilter comienza con:

Rellena {@link SecurityContextHolder} con la información obtenida del {@link SecurityContextRepository} configurado antes de la solicitud y la almacena de nuevo en el repository una vez que se completa la solicitud y se borra el titular del contexto. De forma predeterminada, usa un {@link HttpSessionSecurityContextRepository}. Consulte esta clase para obtener información sobre las opciones de configuración relacionadas con HttpSession.

Por cierto: HttpSessionSecurityContextRepository es la única implementación de SecurityContextRepository (he encontrado en las libs predeterminadas)

Funciona así:

  • El HttpSessionSecurityContextRepository utiliza httpSession (Key = “SPRING_SECURITY_CONTEXT”) para almacenar un Objeto SecurityContext .
  • SecurityContextPersistenceFilter es un filtro que usa un SecurityContextRepository por ejemplo, el HttpSessionSecurityContextRepository para cargar y almacenar objetos SecurityContext . Si una HttpRequest pasa el filtro, el filtro obtiene el SecurityContext del repository y lo coloca en SecurityContextHolder ( SecurityContextHolder#setContext )
  • SecurityContextHolder tiene dos métodos setContext y getContext . Ambos usan una SecurityContextHolderStrategy para especificar qué se hace exactamente en los métodos set y get-Context. – Por ejemplo, ThreadLocalSecurityContextHolderStrategy utiliza 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.