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

Question

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

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

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

Предположим, пользователь приложения пытается удалить конкретное сообщение и разрешено только пользователям с ролью «admin».

Следующие запросы должны быть сделаны:

• приложение -> Auth

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

• приложение -> сообщений

  Удалить пост.

• сообщений -> Auth

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

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

Спасибо!

Answer 1

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

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