Spring Cloud + Zuul + JWT для значений / эталонных токенов

После прочтения статьи Как контролировать личность пользователя В микросервисах я пытался реализовать такую ​​схему управления доступом (значения и ссылочные токены), но после ознакомления с множеством других тем и примеров в GitHub, связанных с Spring Security + OAuth + Zuul, я не смог найти конкретных примеров того, как этого можно достичь. Все примеры, в которых используется JWT, возвращают сведения о пользователе при возврате токена, и именно этого я бы хотел избежать. Сведения о пользователе никогда не должны доходить до Клиента напрямую, а должны передаваться серверным службам. Учебник Spring Security + AngularJs содержит много информации о том, как преобразовать приложение в безопасное, но использует токен доступа или упоминает возможность получения сведений о пользователе напрямую через JWT.

Этот вопрос SO, Использование Zuul в качестве шлюза аутентификации от @ phoenix7360, это именно тот подход, который я пытался реализовать, но он предоставляет лишь краткий обзор конфигурации, необходимой для реализации такого подхода к безопасности для микросервисы. Пожалуйста, обратитесь к изображению в этом вопросе, чтобы получить четкое представление о том, как это будет происходить.

Я не могу полностью понять, как следует настроить предварительный фильтр Zuul и как должна выглядеть конфигурация сервера авторизации. Как указано как в статье, так и в вопросе SO, поток будет примерно таким:

Внешний (HTTPS)

  1. Клиент аутентифицируется на сервере OAuth2.
  2. Сервер OAuth возвращает непрозрачный токен доступа (UUID без другой информации)
  3. Клиент отправляет запрос на шлюз API с токеном доступа в заголовке авторизации.
  4. Шлюз API запрашивает сведения о пользователе на сервере OAuth с помощью токена доступа в заголовке авторизации.
  5. Сервер OAuth проверяет, что токен доступа действителен, и возвращает информацию о пользователе в формате JSON.

Внутренний (HTTP / S)

  1. API Gateway создает JWT с данными пользователя и подписывает его закрытым ключом.
  2. API-шлюз добавляет JWT для запроса и перенаправляет его на сервер ресурсов.
  3. Сервер ресурсов проверяет JWT с помощью открытого ключа API Gateway.

Примечание. Шлюз API должен возвращать ошибку, если сервер OAuth указывает, что токен доступа больше не действителен.

Как будет работать ZuulFilter? Требуется ли новый запрос к серверу OAuth (например, через RestTemplate), или эти схемы поддерживаются текущей реализацией? Требуется ли какая-либо конкретная конфигурация для классов JavaConfig как для OAuth, так и для Zuul? Если кто-то знает рабочий пример, он был бы действительно полезен и был бы отличным справочником по этой теме в будущем.

Я использую Spring Boot (1.4.0-M3) + Spring OAuth + Spring Cloud (Eureka, Ribbon, Zuul)

Я знаю, что этот вопрос очень похож на тот, который был связан ранее, и если это неправильный способ сделать это, я прошу прощения, но я подумал, что новый поток будет лучше, чем просить помощи в потоке SO, который направлен на решение другой проблемы .

Заранее спасибо!


spring-boot jwt spring-security oauth netflix-zuul
person Tom Kelly    schedule 02.07.2016    source источник
comment
github.com/azizkhani/PiggyMetrics   -  person ali akbar azizkhani    schedule 23.03.2017
comment
jhipster.github.io/microservices-architecture   -  person ali akbar azizkhani    schedule 23.03.2017
comment
если вы хотите иметь UAA, я думаю, что zuul доза не нуждается в проверочном токене и вызывает AuthorizeServer. но когда у вас нет UAA, я думаю, что Api Gateway является AuthorizeServer. но в службе для вызова службы требуется OAuth2RestTemplate, который получает токен перед вызовом метода обслуживания   -  person ali akbar azizkhani    schedule 23.03.2017
comment
зачем вам делать это в шлюзе? Я понимаю, хотите ли вы проверять входящие JWT на достоверность, на всякий случай, но ваши службы также должны будут потреблять (и проверять) токены. но в целом ваш поток кажется хорошим. за исключением одного: запрос с токеном доступа Oauth должен быть сначала проверен, а затем после успеха вы можете создать JWT и подписать его - и выдать ошибку, если токен плохой. вам также нужно будет рассмотреть конечную точку для других служб, чтобы получить открытый ключ, необходимый для проверки подписи.   -  person rmalchow    schedule 31.07.2018

Ответы (1)


arrow_upward
1
arrow_downward

JHipster неплохо справляется с этой проблемой. Если я хочу кратко рассказать о процессе входа в систему, сначала вы входите в систему, а когда вы получаете всю информацию, которую необходимо передать вашим нижеприведенным службам (например, имя пользователя, адрес электронной почты и т. Д.), Вы передаете их своим микросервисам. вы можете увидеть ссылку ниже из okta для получения дополнительной информации https://developer.okta.com/blog/2018/03/01/develop-microservices-jhipster-oauth

person ksadjad    schedule 03.11.2018