Это зависит от того, как вы его настроили (или, скажем, вы можете настроить другое поведение).
В веб-приложении вы будете использовать ThreadLocalSecurityContextHolderStrategy
, который взаимодействует с SecurityContextPersistenceFilter
.
Документ Java на SecurityContextPersistenceFilter
начинается с:
Заполняет {@link SecurityContextHolder} информацией, полученной из настроенного {@linkSecurityContextRepository} до запроса и сохраняет его в хранилище после завершения запроса и очистки держателя контекста.По умолчанию он использует {@link HttpSessionSecurityContextRepository}.См. Этот класс для получения информации о параметрах конфигурации, связанных с HttpSession.
Кстати: HttpSessionSecurityContextRepository - единственная реализация SecurityContextRepository (я нашел в библиотеках по умолчанию)
Itработает следующим образом:
-
HttpSessionSecurityContextRepository
использует httpSession (Key = "SPRING_SECURITY_CONTEXT") для хранения SecurityContext
объекта. SecurityContextPersistenceFilter
- это фильтр, который использует SecurityContextRepository
, например HttpSessionSecurityContextRepository
для загрузки и хранения SecurityContext
объектов.Если HttpRequest проходит фильтр, фильтр получает SecurityContext
из хранилища и помещает его в SecurityContextHolder (SecurityContextHolder#setContext
) - .
SecurityContextHolder
имеет два метода setContext
и getContext
.Оба используют SecurityContextHolderStrategy
, чтобы указать, что именно делается в методах set- и get-Context.- Например, ThreadLocalSecurityContextHolderStrategy
использует локальный поток для хранения контекста.
Итак, подведем итог: пользовательский субъект (элемент SecurityContext) хранится в сеансе HTTP.И для каждого запроса он помещается в локальный поток, откуда вы к нему обращаетесь.