Блог

В компании, в которой я работаю; мы планируем пользовательскую службу прав доступа (используя Open Policy Agent в качестве механизма политики) для детального принятия решений по авторизации.

Высокоуровневая архитектура выглядит следующим образом:

В основном микросервисы с поддержкой прав доступа передают идентификатор (JWT subject), операцию (GET / POST / PUT / PATCH / DELETE) и ресурс ( /thing/12345 ) службе прав доступа, чтобы получить решение authZ. Решение — это просто логический ответ разрешить / запретить. Права доступа сохраняют информацию о пользователях, группах и ролях (которую он получает асинхронно от IDP и других систем), поэтому он может искать эту информацию из своего локального источника данных и передавать ее в OPA (используя перегруженный шаблон ввода). Права доступа / OPA просто выполняются как автономная служба — мы не запускаем OPA как вспомогательный инструмент или что-то в этом роде…

Проблема, которую мы пытаемся решить, заключается в том, что для большинства маршрутов владелец ресурса не является частью пути к ресурсу, но нам все равно нужен владелец ресурса, чтобы иметь возможность принимать решение authZ.

Я могу придумать 3 способа получить доступ владельца ресурса к правам доступа. Я хочу получить несколько советов о том, какой подход был бы наилучшим.

1. Включите информацию о владельце ресурса во все пути к ресурсам, например, /user/{id}/thing/12345 . TBH не уверен, насколько жизнеспособным будет этот подход в нашей экосистеме, поэтому, вероятно, это было бы моим наименьшим предпочтением.
2. Службам с поддержкой прав доступа необходимо найти владельца ресурса (для данного ресурса) и передать его в права доступа (вместе с идентификатором, операцией и ресурсом).
3. Синхронизируйте идентификаторы ресурсов (сопоставленные владельцам ресурсов) с правами доступа по мере создания ресурсов, чтобы службы с поддержкой прав доступа могли впоследствии просто передавать идентификатор, операцию и ресурс для получения решения authZ.

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

Поиск данных разрешения с запросом или в политике

Плюсы:

• Известно, что данные обновлены на момент принятия решения.

Минусы:

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

Хранение данных разрешения в памяти

Плюсы:

• Поскольку поиск выполняется из памяти, они обычно выполняются очень быстро.

Минусы:

• Данные актуальны только на момент последней синхронизации.
• Если не представляется возможным отправлять все данные с каждым обновлением, необходимо реализовать и поддерживать пользовательскую логику только для синхронизации различий / дельт. Сложность этого в значительной степени зависит от базового источника данных.
• В зависимости от размера данных может потребоваться много памяти, особенно если она распределена между многими экземплярами OPA, поскольку все они будут содержать копию данных.