Как разработать правила авторизации ABAC в CQRS и подключить их к домену?
Некоторое время изучал сайты с CQRS/DDD, но у меня все еще есть проблемы с пониманием того, как сделать авторизацию с CQRS/ES (со стороной записи и стороной чтения).
Допустим, у меня есть приложение, которое имеет следующее:
- Агрегат компании
- Агрегат пользователей
- Пользователь, который может играть несколько ролей
- Супер Администратор, Администратор, Администратор, Менеджер, Клиент и т. Д.
- Бизнес-правила для контроля доступа
- Примеры:
- "Клиент, который приобрел у данного Бизнеса, может оценить, как Бизнес позаботился о заказе, но только после того, как заказ был завершен (и дата заказа прошла)".
- "Администраторы магазина и компании могут назначать и удалять менеджеров из своих магазинов".
- Для приложения важно вести историю изменений авторизации, сделанных пользователями системы. Поэтому, если Администратор изменяет определенную Политику авторизации для Менеджера, будет важно позже увидеть это изменение.
Как я понимаю, если авторизация является неотъемлемой частью вашего бизнес-процесса, она должна быть близка к вашему домену. И поскольку мои события являются единственным источником правды, навсе (или большинство?) Вопросов об авторизации должен отвечать мой домен... моя сторона записи?
Итак, позвольте нам сказать, что мы решили использовать ABAC (PBAC) для авторизации (открыт для предложений использовать что-то другое). Надежды на то, что ABAC полностью позволит нам очень детально контролировать авторизацию / бизнес-логику. Мы можем создавать Политики с атрибутами, определяющими Роли, Действие, Ресурсы и Среду (как в ABAC: Атрибуты Субъекта, Атрибуты Объекта, Условия окружающей среды, а также формальные правила отношения или контроля доступа, определяющие допустимые операции для субъекта-объекта. комбинации атрибутов и условий среды)
Тогда вопросы:
Каковы эти политики или, что более важно, как они живут в приложении? По сути, они являются объектами домена, которые создаются через поток событий, а также из любого другого агрегата, который есть в системе / домене? Я видел много ответов, таких как "Не изобретать велосипед", "Использовать установленные библиотеки авторизации" и т. Д.Поэтому, по сути, если приложению CQRS необходимо отслеживать изменения авторизации (Event Sourcing их), а также выполнять проверки авторизации как бы вы их реализовали на основе определенных политик ABAC как на стороне записи, так и на стороне чтения?
Как запросы (наша сторона чтения) использует их, если вообще? Я думал о 4 различных способах, которыми мы можем проектировать проверки авторизации:
- Как на стороне записи, так и на стороне чтения используется сторона записи, чтобы ответить на вопрос, касающийся авторизации (Как это влияет? Производительность падает для стороны чтения, запрашивающей сторону записи?) [Политики на стороне записи (домен)] ИЛИ
- Каким-то образом смоделируйте сторону чтения так, чтобы она не выполняла проверки авторизации, а скорее обслуживала данные для каждого отдельного пользователя [Политики проверки на стороне записи, соединения (sql) и user_id на стороне чтения], ИЛИ
- Сторона чтения дублирует политики стороны записи. (Значит ли это, что мы должны написать нашу логику авторизации дважды? (Логика для стороны записи и логика для стороны чтения)?) [Политики на стороне записи, Политики на стороне чтения], ИЛИ
- И наоборот, сторона записи создает политики, поступающие со стороны чтения. (Таким образом, для того, чтобы любая команда была авторизована, мы сначала обращаемся к стороне чтения и строим наши политики. Падение производительности для стороны записи?) [Политики на стороне чтения]
Кажется, ничто не может быть лучшим подходом, и все они, похоже, либо приводят к снижению производительности (проверяют политики, построенные на стороне записи, как на стороне записи, так и на стороне чтения), так и дублируют код (проверяют политики отдельно на стороне записи и на стороне чтения).
TL; DR
Таким образом, по сути, если приложению CQRS необходимо отслеживать изменения авторизации (их получение из событий), а также выполнять проверки авторизации на основе определенных политик ABAC как на стороне записи, так и на стороне чтения, как бы вы их реализовали?