Должен ли каждый микросервис управлять своими собственными правами и ролями пользователей?

У меня есть проблема с дизайном, которую я не знаю, как решить.

Предположим, что мое основное приложение состоит из 6 модулей:
  • клиент
  • шлюз
  • auth-service
  • форум
  • галерея
  • сообщения

Клиент должен взаимодействовать только со службой шлюза.

Должен ли мой шлюз выполнять аутентификацию пользователя (что в идеале приводит к JWT) и другие 3 продуктивные службы (форум, галерея, сообщения) просто проверьте этот маркер и извлеките разрешения и роли , которыми они управляют сами для данного пользователя?

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

Нажмите здесь для оригинала draw.io графика, если вам так больше нравится.

Я не хочу использовать какие-либо сторонние auth-сервисы; я просто хочу, чтобы мой auth-сервис (что в значительной степени сделано) регистрировал пользователей и позволял им входить в систему. Или я должен управлять разрешениями и ролями в и эта служба тоже?

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

Любая помощь здесь приветствуется!

П. С.: Я прочитал стратегии проверки подлинности конструирование иаутентификация шлюза Zuul - Api , но оба они, похоже, не применимы в моем случае.

2 3
jwt microservices

2 ответа:

Я работал со следующей установкой, и она сработала довольно хорошо:

Поток входа в систему:

  1. свежий браузер делает запрос на определенный ресурс
  2. служба шлюза обнаруживает отсутствие файла cookie jwt и перенаправляет его на форму входа
  3. форма входа ведет переговоры с auth-сервисом через шлюз. Шлюз позволяет не вышлю звонки только на авт-сервис
  4. служба Auth выдает логин-форму вновь созданного JWT cookie и перенаправляет на исходный URL

Нормальный операция:

  1. браузер делает запрос на ресурс вместе с JWT cookie
  2. служба шлюза перехватывает запрос и перенаправляет jwt в auth-service для проверки
  3. служба Auth проверяет подпись, затем отметку времени, затем черный список и возвращает положительный или отрицательный результат
  4. в случае положительного ответа служба шлюза пересылает запрос в соответствующую серверную службу, в противном случае перенаправляет запрос на вход
  5. серверная служба не выполняет проверку jwt - она просто доверяет шлюз для отправки только действительных запросов.
  6. серверная служба проверяет наличие ролей / разрешений/прав, определенных в jwt

Поток выхода из системы:

  1. браузер делает запрос на auth-сервис / выход из системы
  2. служба Auth помещает jwt в черный список и перенаправляет на форму входа

Теперь это простой рабочий процесс, который мы реализовали без какой-либо (много) сторонней помощи. В какой-то момент нам пришлось использовать сеансовые куки, но это по другим причинам. Обратите внимание, что система практически не имеет состояния, за исключением черного списка в службе auth. нельзя просто выйти из системы с помощью jwt!У нас был редис для управления черными списками. Вы можете реализовать выход из системы с помощью сеансовых файлов cookie в gateway или auth service.

Большинство серверных служб ожидали свой собственный набор ролей / привилегий/прав в jwt. Роли были предоставлены пользователю службой auth и записаны в предоставленном jwt. Если пользователю была назначена новая роль, он должен был выйти из системы/войти в систему. отразите эту привилегию. Если какая - то привилегия удалена, то пользователь должен был принудительно выйти из системы-вот где играл REDIS.

2

Это зависит от того, насколько сложна настройка разрешений.

Если ваши разрешения очень просты, то есть все службы нуждаются в аутентификации и имеют одну роль a для работы, вы можете добавить в gateway api.

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

1