Централизованная аутентификация в сервис-ориентированной архитектуре

Я изучаю базовую сервис-ориентированную архитектуру, и мне интересно, как лучше всего обрабатывать аутентификацию пользователей во всех службах.

В качестве очень простого примера предположим, что у нас есть приложение для блога, которое обращается к двум другим службам:

  • Служба пользователя/авторизации для хранения пользовательских данных и обмена учетными данными для токена доступа
  • Служба сообщений для управления почтовыми данными

Скажем, пользователь приложения пытается удалить конкретный пост и что разрешено делать это только пользователям с ролью "admin".

Необходимо выполнить следующие запросы:

  • app → auth

    Аутентификация текущего пользователя (через какой-то токен). Если токен истек, приложение может перенаправить пользователя в форму входа и т.д.

  • app → posts

    Удалить сообщение.

  • posts → auth

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

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

Спасибо!

Ответы

Ответ 1

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

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