Да, используем XACML, так как это единственный стандарт на сегодняшний день. Большие правила безопасности, написанные на XACML, действительно могут выглядеть очень монструозно, но с этим можно справиться. Тут весь вопрос заключается в инструменте администрирования этих политик безопасности. Я постараюсь осветить этот момент максимально подробно, показав в следующей статье как можно с этим справиться.
Программирование для этого не нужно. В бизнес-правилах вы оперируете теми атрибутами, которые и так уже должны быть в бизнес-модели. Все что вам требуется для проверки прав доступа, это найти значения перечисленных в правилах безопасности атрибутов и проверить их. Этим поиском и проверкой должна заниматься инфраструктура системы контроля доступа. Грубо говоря, в момент проверки прав вы отдаете все учавствующие в действии объекты и правила безопасности в систему контроля доступа. Она, в свою очередь, находит в объектах указанные в правилах атрибуты, получает их значения и проводит необходимые вычисления.
Вы еще раз подтвердитили то, что написано в статье. Одних ролей вам не достаточно и вы добавляете новый инструмент — «правила» для того, чтобы оперировать аттрибутами. А это как раз и есть ABAC.
Давайте, если уж мы ведем беседу — вести ее по существу.
Отвечая на ваш вопрос, могу сказать, что ACL есть даже во многих популярных дистрибутивах линукса. Очевидно, что его понимает несколько больший круг людей, чем вы предполагаете.
Еще раз хочу заметить, что RBAC имеет ряд существенных проблем, в том числе и так называемая «role explosion». На примере исследования видно, что количество ролей обычно превышает количество пользователей в 1.5 раза. Представьте, насколько сложным становится администрирование такой огромной матрицы, если в компании несколько сотен или тысяч человек. Все эти проблемы призван решать ABAC.
Ваш комментарий еще раз подтверждает то, что написано выше: средствами одной ролевой модели решить все проблемы доступа невозможно, для чего вводятся дополнительные инструменты. Из-за этого бизнес-правило «размазывается» по этими инструментам. Не имея жесткой связи между своими частями, это бизнес-правило легко может быть нарушено, если изменить одну его часть и забыть поменять другую.
Особенно, учитывая, что матрица для компании в несколько тысяч человек или десятков тысяч человек будет огромная.
Доступ к данным, конечно, можно разграничить заранее, если известно по какому принципу, но что делать, если это заранее неизвестно? Пример навскидку: «Младший менеджер может подтверждать только те заказы, в которых товары находятся на складе, расположенном в том же городе, что и заказчик».
Не говоря уже о проверке атрибутов среды, таких как время или местоположение. Они дают возможность запрещать выполнения некоторых действий в нерабочее время, или при нахождении за пределами компании.
Подход с атрибутами позволяет задавать правила любой сложности и делать их компактными и наглядными. Глядя на них, даже обычный бизнес-пользователь поймет, что они означают. Их легко будет поддерживать, не обладая специфическими знаниями различных инструментариев. И уж тем более не придется вникать во всю матрицу, чтобы правильно расставить чекбоксы.
Правила доступа в ABAC являются проекцией бизнес правил и поэтому логично, что они используют уже существующие бизнес-атрибуты из вашей бизнес модели. Если сущностям требуется добавлять какие-то неизвестные бизнесу атрибуты для разграничения прав доступа, то это выглядит странно.
Если есть такой бизнес смысл, то где-то в системе должен быть признак присутствия или отсутствия начальника. Он и будет являться атрибутом используемым в правилах доступа.
Я думаю, что мы постепенно уйдем от использования dynamic, тем более, в будущих планах это и так было.
Property injection используется в нескольких местах в проекте. Constructor injection рекомендуют использовать для обязательных зависимостей. Если зависимость не обязательна (есть какая-то установленная по умолчанию реализация, которую можно заменить при необходимости), то тогда используют property injection.
Мне кажется, что эти стратегии нельзя отключить отдельно, т.к. они являются частью поведения по умолчанию.
Отвечая на ваш вопрос, могу сказать, что ACL есть даже во многих популярных дистрибутивах линукса. Очевидно, что его понимает несколько больший круг людей, чем вы предполагаете.
Еще раз хочу заметить, что RBAC имеет ряд существенных проблем, в том числе и так называемая «role explosion». На примере исследования видно, что количество ролей обычно превышает количество пользователей в 1.5 раза. Представьте, насколько сложным становится администрирование такой огромной матрицы, если в компании несколько сотен или тысяч человек. Все эти проблемы призван решать ABAC.
Особенно, учитывая, что матрица для компании в несколько тысяч человек или десятков тысяч человек будет огромная.
Доступ к данным, конечно, можно разграничить заранее, если известно по какому принципу, но что делать, если это заранее неизвестно? Пример навскидку: «Младший менеджер может подтверждать только те заказы, в которых товары находятся на складе, расположенном в том же городе, что и заказчик».
Не говоря уже о проверке атрибутов среды, таких как время или местоположение. Они дают возможность запрещать выполнения некоторых действий в нерабочее время, или при нахождении за пределами компании.
Подход с атрибутами позволяет задавать правила любой сложности и делать их компактными и наглядными. Глядя на них, даже обычный бизнес-пользователь поймет, что они означают. Их легко будет поддерживать, не обладая специфическими знаниями различных инструментариев. И уж тем более не придется вникать во всю матрицу, чтобы правильно расставить чекбоксы.
Property injection используется в нескольких местах в проекте. Constructor injection рекомендуют использовать для обязательных зависимостей. Если зависимость не обязательна (есть какая-то установленная по умолчанию реализация, которую можно заменить при необходимости), то тогда используют property injection.
Мне кажется, что эти стратегии нельзя отключить отдельно, т.к. они являются частью поведения по умолчанию.