Аутентификация — это проверка, что пользователь есть тот, за кого себя выдает. Чтобы выполнить проверку, надо:
- Извлечь имя и пароль из HTTP-запроса. За это отвечает UsernamePasswordAuthenticationFilter (конкретно в нашем приложении с Form-Based аутентификацией).
- Сравнить их с реальными именем и паролем, хранящимся где-то (в базе, на LDAP-сервере, во временной памяти приложения и т.д. где угодно). Это делает AuthenticationManager в методе authenticate().
Вызывается authenticate() из фильтра UsernamePasswordAuthenticationFilter сразу после извлечения имени/пароля из HTTP-запроса.
Метод authenticate(Authentication authentication) интерфейса AuthenticationManager — проверка пароля
Допустим, нам приходит HTTP-запрос. Прежде чем попасть в контроллер, запрос проходит через цепочку фильтров. В UsernamePasswordAuthenticationFilter имя и пароль вытаскиваются из запроса. Дальше надо их сравнить с реальными. Тут то вступает в дело AuthenticationManager:
Включаем ЗАВОДСКУЮ РАЗБЛОКИРОВКУ SAMSUNG (OEM Unlock, разблокировка загрузчика) для TWRP!
public interface AuthenticationManager
Его единственный метод authenticate() выполняет аутентификацию, то есть решает, действительно ли пользователь тот, за кого себя выдает. Делегируется проверка конкретным провайдерам (в зависимости от того, как хранится реальный пользователь, проверка разнится).
Authentication до аутентификации
Как видно в коде выше, метод authenticate() получает на вход объект Authentication с именем и паролем, полученными от клиента и требующими проверку. Имя хранится в principal, а пароль в credenticals (до проверки, после проверки будет иначе):
Содержимое объекта Authentication можно проверить, если запустить предыдущий пример и поставить break-point в методе authenticate() класса ProviderManager. А потом по адресу /login отправить POST-запрос с формы ввода имени/пароля:
public class ProviderManager implements AuthenticationManager, MessageSourceAware, InitializingBean
Найти класс ProviderManager — Ctrl+N в IntelliJ IDEA
isAuthenticated() до аутентификации равно false.
Если аутентификация не прошла (имя и пароль неверны), то выбрасывается исключение BadCredentials.
В случае же успеха возвращается тоже объект Authentication, но заполненный по-другому.
Authentication после аутентификации
После аутентификации в поле Principal объекта Authentication будет реальный пользователь в виде UserDetails:
При этом поле Credentials обнуляется, а isAuthenticated() меняется с false на true.
public interface UserDetails extends Serializable < CollectiongetAuthorities(); String getPassword(); String getUsername(); boolean isAccountNonExpired(); boolean isAccountNonLocked(); boolean isCredentialsNonExpired(); boolean isEnabled(); >
То есть имя и пароль перемещаются объект Principal:
Что такое API простыми словами
UserDetails realUser= (UserDetails)authencation.getPrincipal();
Проверить содержимое объекта Authentication после аутентификации можно, внедрив его в контроллер и поставив в нем break-point (смотреть переменные нужно, когда заходишь под уже залогиненным пользователем; поскольку в нашем примере мы настраивали, что путь /user доступен только для залогиненного пользователя, то есть после того, как аутентификация уже успешно прошла):
Вывод в консоль:
Как же AuthenticationManager в authenticate() решает, правильный пароль, или нет? Очевидно, для этого надо сравнить переданный пароль с реальным. А для этого по переданному имени надо извлечь реального пользователя. И вот тут дальнейшее зависит от того, где этот пользователь хранится.
Типы аутентификации в Spring Security
Есть несколько стандартных типов хранения и извлечения пользователя, и за каждый из них отвечает свой AuthenticationProvider. AuthenticationManager делегирует провайдеру извлечь данные их хранилища. В Spring Security реализованы несколько стандартных провайдеров, все они задаются в методе configure():
- In-Memory — простейший, задан в вышеприведенном фрагменте кода из примера
- Jdbc — рассмотрим в следующей статье
- LDAP
А можно написать свой, так чаще всего и делают (тоже сделано в следующей статье).
Все упирается в получение реального пользователя по его имени — в метод loadUserByName интерфейса UserDetailsService:
public interface UserDetailsService
где UserDetails содержит информацию о реальном пользователе (точнее, нам надо составить эту информацию из того, что есть в базе, например).
И составляем мы ее как раз в методе loadUserByUsername(), если реализовываем его вручную. Важно заполнить password, username и authorities (права) объекта UserDetails .
Но вернемся к методу authenticate(), в котором происходит аутентификация.
SecurityContext — хранилище объекта Authentication
Допустим, аутентификация прошла успешно — это значит, имя и пароль верные.
Тогда объект Authentication сохраняется в SecurityContext, а тот, в свою очередь, — в SecurityContextHolder:
Текущего пользователя из него можно получить так:
SecurityContext context = SecurityContextHolder.getContext(); Authentication authentication = context.getAuthentication(); UserDetails principal = (UserDetails) authentication.getPrincipal();
Таким образом, SecurityContext используется для хранения объекта Authentication.
Восстановление Authentication из сессии
Аутентификация в нашем примере происходит только раз. Коль скоро она прошла успешно, authentication восстанавливается из контекста, а в итоге из сессии при последующих запросах. Происходит это в SecurityContextPersistenceFilter.
Сессии в нашем примере включены — они включены по умолчанию, если их специально не отключить. То есть после аутентификации в HTTP-ответе клиенту отправляется уникальный JSESSIONID, который он отправляет во всех последующих запросах. По JSESSIONID восстанавливается сессия, из нее берется SecurityContext, а из него Authentication.
Итоги
В тексте выше приводились примеры кода и ставились break-point приложения из статьи.
В следующем примере напишем пользовательскую аутентификацию с помощью UserDetailsService.
Автор sysout Опубликовано 01.04.2020 24.01.2021 Рубрики Spring, Spring Security
Как устроена Аутентификация в Spring Security: 9 комментариев
Самое интересное для меня за кадром осталось(( Не могли бы описать не просто текстом, а код-снипетами (ну или псевдокодом) вот эту часть таинства из последнего буквально предложения: «По JSESSIONID восстанавливается сессия, из нее берется SecurityContext». Хотелось бы понять как оно работает. В принципе в поисках этого кусочка я и забрел сюда, а и тут нет…..
Буду очень благодарен.
sysout :
1) Если больше интересует 1-часть, а именно как «По JSESSIONID восстанавливается сессия» — то к Spring это особого отношения не имеет. Запущенный контейнер сервлетов Tomcat (независимо от Spring) хранит в куче (по умолчанию в куче, но есть варианты) объекты HttpSession пользователей. Это можно представить как ключ-значение, немного подробнее тут (первая часть статьи). 2) «из нее берется SecurityContext»
За это отвечает в Spring фильтр SecurityContextPersistenceFilter Есть класс HttpSessionSecurityContextRepository implements SecurityContextRepository, так вот в методе SecurityContext loadContext() (а из него в readSecurityContextFromSession()) контекст извлекается в сниппете:
Object contextFromSession = httpSession.getAttribute(springSecurityContextKey) где springSecurityContextKey — строка «SPRING_SECURITY_CONTEXT» — атрибут обычной томкатовской сессии HttpSession. В понятии «атрибут сессии» тоже нет ничего Spring-специфичного. Вот просто есть такой «SPRING_SECURITY_CONTEXT» атрибут, который Spring использует для своих целей — для хранения контекста. Да, а в фильтре SecurityContextPersistenceFilter как раз и вызываются методы сохранения и извлечения контекста из HttpSessionSecurityContextRepository PS Найти класс — Ctrl+N в Idea
sysout :
По 1:
В классе org.apache.catalina.session.ManagerBase (простейший менеджер сессий) есть
Map sessions = new ConcurrentHashMap<>();
Вот в ней как раз хранятся активные сессии и их идентификаторы. В менеджере есть методы add(Session), remove(Session)— добавить и удалить сессию.
Но честно говоря, подробно смотреть код контейнера сервлетов смысла нет, главное — понимать принцип.
Источник: sysout.ru
Как реализовать аутентификацию через токен в Django Rest Framework
Django Rest Framework (drf) поддерживает простую аутентификацию с помощью токена. Такой тип аутентификации чаще всего используется для доступа к API. В этой статье будет показано как использовать такой тип аутентификации в вашем API.
Навигация по посту
- Где используется токен-аутентификация
- Различия обычной токен аутентификации от JWT и OAuth
- Создание токена
- Отправка запросов с токеном
Где используется токен-аутентификация
HTTP является ‘stateless’ протоколом (не хранящий состояния). Это значит, что, каждый запрос для сервера будет новым, хоть вы уже обращались к нему десяток раз. Из-за этого, в заголовке каждого запроса, содержится множество информации, в том числе данные аутентификации.
Аутентификация может работать по разному. Ниже часть популярных реализаций, которые поддерживает Django Rest Framework:
- BasicAuthentication
- TokenAuthentication
- SessionAuthentication
- RemoteUserAuthentication
Преимущество TokenAuthentication и SessionAuthentication над BasicAuthentication в том, что вы передаете пару логин и пароль единожды, а затем можете использовать уникальные идентификаторы. В случае сессий идентификаторы помещаются в заголовок Cookies, а у токенов — сгенерированная строка, например «eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9», в заголовке Authorization.
Аутентификация на основе сессий может создать сложности в некоторых случаях, например:
- Вам нужно использовать одну сессию в нескольких доменах. Во многих случаях это будет невозможно сделать;
- Если у вас несколько клиентов в т.ч. настольные и мобильные приложения. Сессии могут хранить не только данные сессии, но и об приложении. Они могут быть не нужны и с ними будет сложнее работать;
- Токены являются лучшим способом защиты от CSRF атак.
Сам фреймворк drf может одновременно работать с несколькими типами аутентификации. Т.е. использовать сессию для браузера и токен для мобильного приложения.
Различия обычной токен аутентификации от JWT и OAuth
Со словами токен аутентификации так же часто появляются понятия JWT (JSON Web Token) и OAuth 2. Это может создать путаницу. Различие можно понять, если представить строку »eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9″ как токен. Роль этого токена в разных случаях:
- Обычная токен аутентификация — это значение в базе данных, которое связано с пользователем и проверяется в каждом запросе;
- В случае JWT — это закодированные и подписанные данные, которые можно раскодировать и получить JSON строку идентифицирующую пользователя и срок работы токена. Преимущество в том, что запрос к базе данных не делается;
- OAuth 2 — является протоколом авторизации, а не аутентификации. Он определяет какие права будут у другого приложения для доступа к ресурсам пользователя. Отдельно определяется сам токен, который может быть, например, JWT.
Эти возможности реализуются через сторонние библиотеки. JWT, например, можно создать через Dj-Rest-Auth (раннее Django-rest-auth), а OAuth через djangorestframework-oauth.
Создание тестового приложения
Создадим простое приложение, на котором будет показан пример использования аутентификации с токеном. Установим необходимые пакеты:
pip install django djangorestframework
Создадим проект и приложение внутри него:
django-admin startproject api cd api python manage.py startapp app
В файле настроек проекта добавим установленный фреймворк ‘djangorestframework’ и созданное приложение ‘app’ в INSTALLED_APPS:
# api/setting.py INSTALLED_APPS = [ . # Установленные пакеты ‘rest_framework’, # Созданное приложение ‘app.apps.AppConfig’, ]
Создадим вьюшку, которая будет возвращать какое-то сообщение:
# app/views.py from rest_framework.views import APIView from rest_framework.response import Response class Index(APIView): def get(self, request): content = return Response(content)
Свяжем этот класс с URL:
# api/urls.py from django.urls import path from app import views urlpatterns = [ path(», views.Index.as_view()), ]
Выполним миграцию и запустим сервер:
python manage.py migrate python manage.py runserver
В Django Rest Framework предусмотрены заранее готовые разрешения, которые мы можем использовать. Их достаточно много. Мы будем использовать только «IsAuthenticated» проверяющий, что пользователь прошел аутентификацию предоставив верные данные:
from rest_framework.views import APIView from rest_framework.response import Response from rest_framework.permissions import IsAuthenticated class Index(APIView): permission_classes = (IsAuthenticated,) def get(self, request): content = return Response(content)
Теперь, при открытии страницы, будет появляться сообщение »Authentication credentials were not provided.» и 403 ошибку так как мы не аутентифицированы. Так же может быть 401 ошибка, если у вас будет возвращаться заголовок с «WWW-Authenticate» (может зависеть от установленных классов аутентификации).
Настройка аутентификации
Токен-аутентификация работает через отдельное приложение, которое нужно подключить в «INSTALLED_APPS». Это приложение устанавливается вместе с django rest framework:
# api/settings.py INSTALLED_APPS = [ . # Установленные пакеты ‘rest_framework’, ‘rest_framework.authtoken’, # Созданное приложение ‘app.apps.AppConfig’ ]
После добавления приложения нужно обновить настройку указывающие, что drf будет принимать токены для аутентификации. Это делается через следующий код:
# api/settings.py REST_FRAMEWORK =
Подобная настройка говорит, что если будет требоваться аутентификация для drf приложений, она будет работать только через токен. Вы можете добавить и другие классы. Например с ‘rest_framework.authentication.SessionAuthentication’ вы сможете использовать ваши drf приложения через браузер.
После этого повторно выполнить миграцию:
python manage.py migrate
Предыдущий пример указывал тип аутентификации который будет использоваться по умолчанию, но вы так же можете указать его отдельно. Для вьюшек есть атрибут, а для функций декоратор:
. from rest_framework.authentication import SessionAuthentication class Index(APIView): permission_classes = (IsAuthenticated,) authentication_classes = (SessionAuthentication,) .
Создание токена
Токен выдается какому-то пользователю. Если у вас нет пользователя, то можете его создать:
Один из способов отправки токена — это ‘manage.py’. В примере ниже мы выдадим токен пользователю ‘test’:
python manage.py drf_create_token test
Кроме получения токена через ‘manage.py’ это можно сделать по url. Для этого есть отдельная вьюшка ‘obtain_auth_token’, которую нужно указать в ‘urls.py’:
# api/urls.py from django.urls import path from app import views from rest_framework.authtoken.views import obtain_auth_token urlpatterns = [ path(», views.Index.as_view()), path(‘token/’, obtain_auth_token), ]
После этого мы можем обращаться по url ‘http://127.0.0.1/token’ для получения токена. Пример с requests:
import requests url = ‘http://127.0.0.1:8000/token/’ r = requests.post(url, data= < ‘username’: ‘test’, ‘password’: ‘test’ >)
Процесс получения токена достаточно простой. В случае вьюшки ‘obtain_auth_token’ — это наследование с APIView, использование сериализатора, со сверкой логина и пароля, и модели ‘Token’, которая генерирует и сохраняет токен. Сама таблица с токеном выглядит так:
Пример создания токена через shell и модель.
Отправка запросов с токеном
Что бы передать токен его нужно поместить в заголовок ‘Authorization’. Пример через requests:
import requests url = ‘http://127.0.0.1:8000/’ r = requests.get(url, headers= < ‘Authorization’: ‘Token 8072f04f9a1eacbd52fcf7d8289a52245f2454eb’ >)
Или в Powershell и Curl:
Источник: fixmypc.ru