Реализация аутентификации и авторизации с использованием Zuul Proxy, Oauth2 на REST Microservices

Question

Я пытаюсь реализовать вышеуказанную архитектуру в рабочем процессе с помощью Spring Boot.

• Веб-клиент отправляет запрос на сервер ресурсов (конечные точки микросервисов) через Zuul Proxy.
• Zuul Proxy перенаправляет на сервер oauth2 для аутентификации.
• Oauth2 перенаправляет на Zuul Proxy, если запрос аутентифицирован или нет.
• Если аутентификация не выполнена, Zuul перенаправляет веб-клиент с неаутентифицированным ответом.
• В случае аутентификации прокси-сервер Zull перенаправляет на запрошенную конечную точку микросервиса.
• Конечная точка микросервиса проверяет, авторизован ли пользователь (доступ на уровне пользователя) для доступа к ресурсу.
• Микросервис также может выполнять внутренний вызов покоя для другого микросервиса.
• Наконец, запрошенный ресурс отправляется обратно клиенту.

Я хочу убедиться, что выполняю правильный рабочий процесс.

Я хотел бы знать, существует ли какое-либо решение, в котором реализован аналогичный вид защиты API-интерфейсов микросервисов.

У меня путаница с:

• Как мы можем передать данные пользователя на микроуслуги, чтобы микросервисы могли выполнять собственный уровень авторизации пользователя?
• Должен ли заголовок OAuth2 Access Token передаваться каждому микросервису, чтобы микросервисы могли проверять токен отдельно?
• Должен ли каждый микросервис использовать секретные учетные данные для проверки токена доступа, чтобы токен не мог быть подделан в цепочке запросов?

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

Answer 1

Я боролся с той же проблемой проектирования безопасности для микросервисной архитектуры, основанной на весеннем облачном решении.Я только нахожу, что эта статья проливает некоторый свет на это: https://developer.okta.com/blog/2018/02/13/secure-spring-microservices-with-oauth

Но это относится к поставщику услуг Okta sso, а не к универсальному решению для другого сервера oauth2, такого как keycloak.

Я также видел некоторыеРешения о том, как защитить шлюз и микросервис с помощью сервера oauth2, как этот: https://github.com/jgrandja/oauth2login-gateway

Но это не учитывает веб-клиента.

Answer 2

К сожалению, у меня нет полного ответа, только некоторые части:

Как только токен JWT станет доступным для прокси-сервера zuul, каждый микросервис сможет авторизовать запросы, настроив свой сервер ресурсов, например,

 @Override
  public void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests().anyRequest().access("#oauth2.hasScope('microserviceA.read')").and()
        .csrf().disable()
        .httpBasic().disable();
  }

Области могут управляться микросервисом oauth с базой данных - на основании учетных данных клиента он будет получать информацию об областях и кодироваться в токен JWT.

Чего я не знаю в данный момент - как заставить прокси-сервер zuul использовать учетные данные «веб-клиента» для авторизации с помощью oauth - я не хочу жестко кодировать учетные данные прокси-сервера zuul, потому что тогда кредиты клиентов не будут использоваться.

Я только что опубликовал похожий вопрос на эту тему: Авторизация запросов через весенний шлюз с zool через oauth-сервер

обновление: Я нашел статью, описывающую почти эту конфигурацию (без эврики, но это не добавляет особой сложности из моего опыта): https://www.baeldung.com/spring-security-zuul-oauth-jwt, есть проект github с исходным кодом. К сожалению, исходный код не отшлифован, поскольку автор использует его для своих коммерческих курсов. Но мне удалось собрать из его примеров рабочий набор.

Резюме: в описанной архитектуре каждый сервер ресурсов (микросервис A, B, ..) получает токен JWT, пересылаемый прокси / шлюзом zuul от запрашивающего клиента. Токен передается в заголовке запроса. Если действительный токен не предоставлен, шлюз перенаправит запрос на страницу авторизации. Также каждый сервер ресурсов может проверять токен с помощью службы oauth и, при необходимости, выполнять проверку области, как я писал выше.