Spring Security sessionID как конфигурация токена

Я реализую процесс входа в систему, используя сеанс Spring Security + Spring, чтобы создать функцию входа в систему для REST, такой как серверная служба, которая должна создавать/обслуживать сеанс.

Я не уверен, правильно ли я подхожу к решению, поскольку я использую пользовательскую конечную точку для создания сеанса вручную. Может быть, создание сессии нужно делать в самом методе авторизации? Или, может быть, есть способ заставить Spring создать сеанс после некоторых проверок запроса в бэкэнде? Я использую для этого собственный фильтр и провайдера.

Кроме того, с моей текущей конфигурацией у меня возникла проблема, поскольку внутренний API создает новый сеанс с каждым запросом, даже если он должен возвращать 401.

Требования к этому решению следующие:

  1. Клиенты будут подключаться к стороннему поставщику аутентификации/авторизации. После проверки провайдер выдаст токен доступа.
  2. API должен проверить токен доступа клиента у стороннего поставщика. После проверки API должен создать сеанс и вернуть клиентам новый токен (или идентификатор сеанса).
  3. Будущие вызовы API должны включать токен (или идентификатор сеанса) в заголовок/файл cookie, чтобы API получал сеанс клиента.

Большой вопрос заключается в следующем: существует ли общий подход к использованию проверки подлинности на основе токенов, связанной с сеансом пользователя? Если да, то что, если мне нужно выполнить пользовательские проверки перед тем, как весенний сеанс создаст сеанс, а также добавить настраиваемые атрибуты в этот сеанс?

Мой код находится здесь: https://github.com/munilvc/api-session/tree/master/src/main/java/com/munilvc/poc/security

Например, некоторые примеры выполнения:

1) Выполните пользовательский вход:

$ curl -X POST http://localhost:8080/app-api/login/createsession -v
> POST /app-api/login/createsession HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.49.1
> Accept: */*
>
< HTTP/1.1 200
< x-auth-token: 15a06ce8-5b34-401a-a05f-a0d933926245
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
< Date: Tue, 29 Aug 2017 01:28:24 GMT
<
171{"username":"username1"}

2) Вызвать другую конечную точку с предоставленным токеном x-auth:

ПРИМЕЧАНИЕ x-auth-token обновляется в ответе. (означает, что создается новый сеанс - этого мы хотим избежать, это также происходит, когда ответ равен 401)

$ curl -X GET http://localhost:8080/app-api/accounts/2 -H "x-auth-token:15a06ce8-5b34-401a-a05f-a0d933926245" -v
> GET /app-api/accounts/2 HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.49.1
> Accept: */*
> x-auth-token:15a06ce8-5b34-401a-a05f-a0d933926245
>
< HTTP/1.1 200
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: DENY
< x-auth-token: 42a5db80-e5e1-4127-bd85-e468af4a8fb2
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
< Date: Tue, 29 Aug 2017 01:29:08 GMT
<
870{"id":3,"name":"Account 3"}

PS: я не уверен, что мне разрешено предоставлять ссылку на код в переполнении стека. Если нет, я также могу вставить код здесь.

Большое спасибо!


person munilvc    schedule 29.08.2017    source источник


Ответы (1)


В зависимости от ваших требований OpenID Connect можно использовать для аутентификации конечного пользователя и авторизации клиента, который затем получит AccessToken. Затем AccessToken можно использовать для вызова внутренних API (серверов ресурсов).

Взгляните на этот пример/руководство о том, как настроить вход в Spring Security 5 для внешнего поставщика OAuth 2.0 или OpenID Connect. Это удовлетворит ваши требования для входа в приложение с использованием внешнего провайдера и создания безопасного сеанса в Spring Security.

Теперь, когда вы вошли в приложение и у клиента есть AccessToken, клиент может использовать этот AccessToken в запросе (заголовок авторизации) для вызова внутренних API (серверов ресурсов). Сервер ресурсов должен быть настроен для проверки входящего файла AccessToken. Взгляните на этот пример (master и jwt-support) о том, как настроить сервер ресурсов.

Я настоятельно рекомендую ознакомиться с структурой авторизации OAuth 2.0 и OpenID Connect Core 1.0.

Удачи!

person Joe Grandja    schedule 01.09.2017