Я изучаю варианты создания системы, обеспечивающей «Контроль доступа к объектам» в архитектуре на основе микросервисов для ограничения доступа к определенным данным на основе запрашивающего пользователя. Полная система контроля доступа на основе ролей (RBA C) уже была реализована для ограничения определенных действий (на основе конечных точек API), однако ничего не было реализовано для ограничения этих действий в отношении одного объекта данных над другим. Отсюда и желание создать систему управления доступом на основе атрибутов (ABA C).
Учитывая требования к системе для ее соответствия назначению и мои собственные приоритеты, чтобы следовать передовым методикам для реализации логики безопасности c чтобы остаться в одном месте, которое я разработал для создания внешнего API «Entity Access Control».
Конечным результатом моего дизайна было что-то похожее на следующее изображение, которое я видел плавающим вокруг (я думаю из axiomatics.com)
Проблема в том, что все рушится в тот момент, когда вы начинаете говорить об API, который отвечает списком результатов.
Например. Конечная точка / api / Customers на API-интерфейсе Customers, принимающая такие параметры, как фильтр запросов, сортировка, заказ и значения лимитов / смещений, чтобы упростить разбиение на страницы, и возвращает список клиентов во внешний интерфейс. Как вы тогда также предоставляете ABA C для каждого из этих объектов в ландшафте микросервисов?
Ужасные решения вышеупомянутой проблемы, проверенной до сих пор:
- Получить первую страницу результаты, отправьте все это в API EA C, получите ответы, отбросьте те, которые отклонены из ответа, получите больше клиентов из БД, проверьте их ... и повторяйте до тех пор, пока не появится страница результатов или не хватает клиентов в БД. Протестировано, что для 14 000 записей (что в моей ситуации вполне разумно) потребуется 30 секунд, чтобы получить ответ API для того, у кого нет разрешения на просмотр каких-либо клиентов.
- При каждом запросе ко всем конечным точкам всех клиентов, запрос будет отправлен в API EA C для каждого клиента, доступного исходному запрашивающему пользователю. Протестировано, что для 14 000 записей полезная нагрузка ответа будет более половины мегабайта для человека, который имеет разрешение на просмотр всех клиентов. Я мог бы разделить его на несколько запросов, но тогда вы просто уравновешиваете размер полезной нагрузки со спамом запроса, и снижение производительности нигде не go.
- Отказаться от возможности просмотра нескольких записей в списке. Это полностью нарушает использование API для нужд клиента.
- Храните все данные и логи c, необходимые для выполнения элементов управления ABA C в каждом API. Это чревато опасностью и, в основном, гарантировано, что оно выйдет из-под контроля моего риска, учитывая область, в которой я работаю.
Примечание: я протестировал 14 000 записей только потому, что это эталон нашего текущее состояние данных. Вполне возможно, что один API может обслуживать 100 000 или 1 млн записей, поэтому все, что включает в себя итерацию по всему набору данных или передачу всего набора данных по проводам, является абсолютно неустойчивым.
Итак, здесь лежит вопрос ... Как реализовать внешнюю систему ABA C в архитектуре микросервисов (в соответствии с диаграммой), в то же время имея возможность обслуживать запросы, которые отвечают несколькими объектами, с помощью фильтра запросов, сортировки, порядка и значений пределов / смещений для облегчения нумерации страниц.