Аутентификация шлюза Zuul - Api

Ответ 1

Мы используем сеанс Spring для репликации сеанса во всех наших сервисах, которые расположены за сервером Zuul Edge. Zuul будет аутентифицировать пользователя, который заполняет учетные данные пользователей и вставляет аутентифицированного пользователя в сеанс. Затем он реплицируется по всем службам, и каждая служба несет ответственность за свои собственные правила и настройки безопасности. Так что, все, что делает Zuul, ищет пользователя в Spring безопасности, а службы на сервере обеспечивают соблюдение правил безопасности, применимых к их потребностям. Таким образом, вы можете изменить каждую услугу самостоятельно, делая шлюз просто глупым прокси.

Хорошим примером этого является учебник Dave Syers о Spring Безопасность и приложение Angular JS. Я также разместил еще один вопрос, связанный с этим, в котором содержится образец того, как мы это делаем, что может помочь.

Ответ 2

• Gateway будет сидеть перед множеством сервисов.

В чем проблема?

• некоторые службы могут предоставлять конечные точки, которые не требуют аутентификации.

Spring Безопасность имеет правило доступа permitAll()

• некоторые службы могут выставлять конечные точки, которым нужен идентификатор сеанса, а некоторые с маркером ", произвольное непрозрачное значение (например, загрузка файл, если вы знаете URL-адрес" трудно угадать"). В интерфейсе API/ SpringБезопасность вы можете настроить все конечные точки с их конкретными требования к аутентификации.

У вашего прокси-сервера Zuul могут быть сеансы. Если вы используете Spring Security OAuth 2.0, вы можете использовать ResourceServerSecurityConfigurer#stateless(false) и активировать сеансы с помощью HttpSecurity#sessionManagement().sessionCreationPolicy(...), чтобы создавать сеансы каждый раз, когда вы получаете действительный токен доступа. Cookie JSESSIONID будет помещен в HTTP-ответ.

• Как вы принудительно применяете фактические сервисные команды для предоставления необходимых настроек для нисходящей службы?

Я не уверен, что я понимаю вопрос здесь, не хотите ли вы принудительно применять ограничения безопасности на уровне API-шлюза (zuul proxy)? или вы пытаетесь иметь "двойные проверки безопасности" как в прокси-сервере, так и в целевом приложении?

• как вы разрешаете изменения настроек аутентификации в шлюзе (в соответствии с потребностями службы) без остановки всего шлюза?

Zuul позволяет динамически добавлять ZuulRoute во время выполнения, если вы используете его как отдельную библиотеку. Обернуто в Spring Security, контекст которого инициализируется один раз во время запуска... Я сомневаюсь, что вы можете легко изменить конфигурацию безопасности во время выполнения.

ИЗМЕНИТЬ, следуя рекомендациям OP в комментариях. Если ваши команды должны нести ответственность за свои правила безопасности, наличие централизованного шлюза является противоречием по дизайну.

Моя интерпретация философии микросервиса заключается в том, что каждое приложение является автономным и отвечает за его полный функциональный охват, а управление безопасностью/доступом является его частью. Вы можете легко проверить маркеры на уровне приложения (либо путем вызова сервера авторизации, либо с помощью JWT), причем каждое приложение определяет, какая область требуется для каждого ресурса. Spring Облако уже имеет OAuth 2.0 starter, или вы можете легко создать его, если используете "plain" Spring Boot.

Таким образом вы можете развернуть отдельные приложения, где бы вы ни захотели (публичное облако или на локальных серверах), без необходимости полагаться на восходящие компоненты для обеспечения безопасности или синхронизировать развертывания конфигурации шлюза с другими командами.

Шлюз API Gateway - это легкий соблазн, но не упускайте из виду риски и ограничения:

• Вы не сможете защитить внутренние вызовы
• Вам придется полагаться на компоненты, входящие в сеть, и принимать входные данные ваших приложений
• Расширенные правила управления доступом могут стать головной болью: как вы получаете индивидуальные разрешения пользователя и т.д.
• Вам придется синхронизировать изменения конфигурации с другими командами.