Как Spring Security поддерживает информацию аутентификации между запросами?

Как Spring Security поддерживает информацию об аутентификации между запросами?

Использует ли он что-то похожее на jSessionId или использует совершенно другой механизм.

Далее я вижу, что AbstractSecurityInterceptor (я имею в виду любую из его реализаций) отвечает за перехват входящего запроса и проверяет, авторизован ли запрос с помощью Authentication.isAuthenticated(), а затем, в зависимости от условия, либо проверяет запрос, либо отправить запрос аутентификации в реализацию AuthenticationManager. Итак, другими словами, как AbstractSecurityInterceptor различает первый запрос и последующий запрос.


spring-boot spring spring-security spring-session jsessionid
person samshers    schedule 07.08.2019    source источник
comment
это связано с файлами cookie jsessionid, каждый запрос браузер отправляет последним как параметр заголовка, затем сервер перехватывает его и проверяет, является ли он аутентифицированным, авторизованным или анонимным сеансом (не то, чтобы этот параметр был идентификатором созданного объекта сеанса на сервере)   -  person Spring    schedule 07.08.2019
comment
как Spring сохраняет сопоставление между jsessionid и сведениями о пользователе, какие классы обрабатывают эту функцию сопоставления. Это именно то, что я ищу, поэтому я могу больше узнать об этих классах.   -  person samshers    schedule 07.08.2019
comment
когда вы входите в систему, в созданном сеансе будет храниться объект контекста безопасности в ключе сеанса SPRING_SECURITY_CONTEXT, поэтому вся информация о безопасности (включая userDetails будет храниться там).   -  person Spring    schedule 07.08.2019
comment
Вы также можете работать без сеанса и без файла cookie сеанса, например. если вы используете JWT. Это токен, выпущенный провайдером идентификации. Клиент добавляет JWT в заголовок HTTP каждого запроса.   -  person Codo    schedule 07.08.2019
comment
ну, jwt - это gr8... его полезная нагрузка объединяет все роли/разрешения пользователя «туда-сюда»... поэтому контекст безопасности не должен беспокоиться о хранении ролей внутри... но вариант использования, который я пытаюсь понять, базовая аутентификация... без JWT или OAuth (по крайней мере, на данный момент).   -  person samshers    schedule 07.08.2019
comment
Но любая информация о JWT, OAuth также приветствуется.   -  person samshers    schedule 07.08.2019

Ответы (1)


arrow_upward
5
arrow_downward

Spring Security использует ссылку SecurityContextRepository для хранения и извлечения SecurityContext для текущего сеанса безопасности.

Реализация по умолчанию — это HttpSessionSecurityContextRepository, который использует javax.servlet.http.HttpSession для хранения/получения SecurityContext.

Базовый контейнер сервлетов получит правильный HttpSession для входящего запроса, как правило, из-за того, что идентификатор сеанса передается в файле cookie или параметре запроса. Для Spring Security это не имеет значения, поскольку он загружается в базовый контейнер сервлета.

person M. Deinum    schedule 07.08.2019
comment
супер. Можете ли вы уточнить, что это не имеет значения, так как это загружается в базовый контейнер сервлета. Вы имеете в виду, что Spring Security не использует идентификатор сеанса, такой как jsessionid. - person samshers; 07.08.2019
comment
Это не так. Он использует servlet-api и позволяет контейнеру сервлетов (Tomcat, Jetty, Undertow) работать со спецификой. Таким образом, Spring Security имеет дело только с HttpSession тем, как это создается, для Spring Security не имеет значения, поскольку он использует только API. - person M. Deinum; 07.08.2019
comment
Другими словами, jsessionid, который мы видим в браузере, исходит от ApplicationServer. И, как и в мире сервлетов, Spring Security также обрабатывает детали (jsessionid), полученные из объекта httpssession. И здесь вместо кода приложения, обрабатывающего httpssession, Spring обрабатывает его прозрачно. И код приложения больше не требует заботы о httpssession и может работать с более высокой абстракцией, т.е. SecurityContext - person samshers; 07.08.2019
comment
HttpSession является частью API сервлета. Безопасность Spring для Интернета использует API сервлета. Это просто сборка Java поверх существующих API. - person M. Deinum; 07.08.2019
comment
Я думаю, что мы на одной странице. Поправьте меня, если я что-то неправильно процитировал в предыдущем комментарии. :-) супер. Лучше быть ясным и перепроверить - это безопасность в конце дня. - person samshers; 07.08.2019
comment
но я вижу одно ограничение с этой абстракцией HttpSession. Я мог бы добавить дополнительную информацию, а не только информацию об аутентификации, в объект HttpSession просто в гибкой манере. Но с безопасностью Spring, похоже, у меня есть немного больше работы ... например, пользовательский объект obj и что-то еще ... что было бы не так гибко. - person samshers; 08.08.2019
comment
Почему тот факт, что вы используете Spring Security, внезапно изменит вашу возможность доступа и использования HttpSession? Кроме того, если у вас есть пользовательский объект, вам нужно будет подключить его к Spring Security (если это пользовательский объект, который вы хотите использовать как UserDetails). - person M. Deinum; 08.08.2019
comment
Давайте продолжим это обсуждение в чате. - person samshers; 08.08.2019
comment
не могли бы вы помочь мне с этим связанным с этим материалом: (какой класс хранит значение JSESSIONID в весенней безопасности?)[stackoverflow.com/questions/65048440/ - person samshers; 29.11.2020
comment
в контексте этих двух Q файл cookie remember-me также должен быть контейнером сервлета, который, в свою очередь, используется Spring-Security. Это правильно? - person samshers; 30.11.2020
comment
куки, как сеансы, являются частью servlet-api. - person M. Deinum; 30.11.2020