Где использовать разрешение домена

Question

Разрешения/авторизация (а не аутентификация) - это сквозная проблема, я думаю.

В архитектуре лука или гексагональной архитектуре, где следует разрешить выполнение? Примеры permissioning обязательно будет:

• Фильтрация данных возвращается к переднему концу (интерфейс, API, или иным образом)
• Проверка, что бизнес-операции могут быть выполнены на всех

В идеале, с помощью Принцип единой ответственности, код, который выполняет бизнес-операции и возвращает данные, вообще не должен знать о полномочиях пользователя. Реализации этой функции должны знать, как выполнять бизнес-операции или запрашивать репозиторий или службу домена - вот и все.

Будет ли обертка/фасад, реализующий тот же интерфейс, что и класс, выполняющий бизнес-операцию, или возвращающий данные, - это место для размещения этого разрешения? Или есть лучший способ?

Кроме того, если лучшая практика заключается в разрешении по видам деятельности, а не по роли, остается ли все еще говорить о том, что разрешение должно выполняться службой, целью которой является просто вернуть данные?

Answer 1

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

Проверка, что бизнес-операция может быть выполнена на всех

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

Фильтрация данных возвращается к переднему концу (UI, API, или иным образом)

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

Для такого типа фильтрации я никогда не нашел способ реализовать его в качестве сквозной задачи. У меня есть либо испеченная фильтрация в бизнес-логике, либо отпадает назад на модели, которая просто отказывается разрешить выполнение запроса из-за отсутствия разрешения.

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

Тем не менее, я не против фильтрации содержимого.Я просто не видел хорошего решения.

Answer 2

Права доступа к действию - это то, где вы имеете разрешения и действия, проверяемые API авторизации. Это то же самое, что и роли и разрешения, и авторизация выполняется путем проверки разрешений на бизнес-объект, для которого мы указали, что роль разрешена. Это дает гибкость, потому что единственное, что исправлено, это разрешения, но мы можем иметь разные роли, определенные в БД независимо от разрешений полностью.

Один из способов полностью отделить логику авторизации от сервисов и бизнес-уровня, который возвращает объект для отображения, - использовать настраиваемые атрибуты авторизации. В этих атрибутах вы можете указать, какие разрешения требуется пользователю для выполнения действия в контроллере MVC.

Извлечение бизнес-объектов, для которых у пользователя есть разрешение и использование их в качестве ввода при вызове службы или репозитория, является хорошим способом отделить логику авторизации от логики обслуживания. Пример этого будет: я пользователь x и имею доступ к клиентам y, t, g и l - дайте мне весь заказ моих клиентов.