Rbac и abac что это
Бипиум
Мы приступаем ко второму блоку платформы Бипиум — правовой политике доступа. Это еще одна особенность, которая отличает Бипиум от других систем на рынке. В этой статье мы просим помощи и совета как создать идеальную систему с точки зрения реальных задач.
Для начала небольшой экскурс в тему:
Виды политик доступа
Ролевая политика (RBAC)
В большинстве систем, в которых есть регламентирование прав доступа, политика разграничения построена на базе ролей (групп). Например, настраивать систему могут администраторы, доступ к клиентам — у отдела продаж. Система на базе ролей называется RBAC (Role-based access control).
Эта система удобна и проста, но в больших компаниях превращается в настоящий ад. Допустим у нас есть роли Руководитель, Бухгалтер, Менеджер. Чтобы решить задачу «Менеджеры видят клиентов из своего города» придется создать множество фиктивных ролей: Менеджеры Москвы, Менеджеры Питера, Менеджеры Казани и так далее. Хуже того, число ролей растет многократно при добавлении еще одной характеристики. Управлять этим становится невозможно.
Ролевая политика с командами
Ребята в Сахаре реализовали политику доступа в 2-х измерениях: роли для разграничения прав действий (видеть, изменять), и «команды» (Teams) для разграничения доступа к объектам. Команды представлены в виде дерева. Члены команды видят объекты, доступные команде и объекты команд, которые входят в неё на всех уровнях дерева. Система сложнее ролевой, зато позволяет не раздувать число ролей, но команды при этом не дают гибкого разграничения доступа к данным.
Атрибутная политика (АВАС)
Например, что делать если задача сформулирована так: «Младшие менеджеры видят заказы своего филиала, если сумма заказа менее 100 000 руб»?
Существует альтернатива ролевой политике — политика на основе атрибутов ABAC (Attribute-based access control). Атрибутом может выступать любое свойство (поле) объекта данных или сотрудника. Например, «сумма заказа > 100 000 рублей» или «город клиента = городу сотрудника». Классно!
Именно эту модель политики доступа мы и планируем внедрить в Бипиум. Но у нас есть вопросы, и мы не готовы принять решение без вашего мнения.
Политика прав доступа Бипиум
Есть данные — объекты, сотрудники — субъекты, действия над данными — привилегии.
Данные описываются свойставами — атрибутами.
Правило связывает эти сущности между собой:
Кто (субъект) → Что может (привилегия) → С чем (объекты) → Какими именно (атрибуты).
Примеры:Михаил может видеть Клиентов со статусом Лид
Топ-менеджеры могут видеть Заказы на Сумму более 100 000 рублей
В Бипиуме нет клиентов, заказов и обращений. Бипиум это конструктор, структура конфигурируемой системы произвольна. Платформа оперирует тремя основными типами объектов: разделы, каталоги и записи. Экземпляры эти типов и являются объектами правовой политики.
Примеры:
Право видеть Раздел 2 (например это «Продажи»)
Право видеть Каталог 5 (например это «Заказы»)
Право редактировать Запись 17 в Каталоге 5 (доступ до Заказа от «Газпрома»).
Эти объекты в Бипиуме подчинены иерархии вложенности: Раздел ← Каталоги ← Записи.
Неделю назад мы запустили систему фильтров. Фильтры позволяют искать записи в каталоге, используя поля каталога как условия. Эти поля называются атрибутами. Результат поиска может зависеть от того, кто его просматривает.
Примеры:
Клиенты со статусом «Лид»
Обращения, созданные «В этом месяце»
Заказы, где ответственный сотрудник «Я»
Набор заданных фильтров каталога можно сохранить как шаблон — Вид. Вид это четвертый тип объектов правовой политики. Его особенность заключается в том, что Запись может попадать в несколько Видов одновременно.
Иерархия увеличивается: Раздел ← Каталоги ← (Виды) ← Записи.
Субъекты правовой политики — это сущности, на которых назначаются права. Самый очевидный субъект это Сотрудник компании. Когда сотрудников много, их удобно группировать. Во многих системах для этого есть Роли. Но ведь Бипиум это конструктор, в нем нет Ролей. Зато их можно создать, если нужны. А заодно и отделы, филиалы, команды, должности и все что угодно. Вы можете создать каталоги, которые описывают иерархию в вашей компании и включить соответсвующие поля в карточку сотрудника. Любой каталог, который связан с Сотрудниками становится субъектом правовой политики. То есть субъектом может быть Отдел, Роль, Должность, Филиал, Кабинет, Навык и так далее.
Привилегии — уровень доступа субъекта к объекту. Например: видеть, изменять, создавать, удалять или администрировать. Привилегии бывают атомарные (когда каждая привилегия не зависит от других) и включающие друг друга. Например, привилегия «редактировать» включает привилегию «видеть» и так далее. Для упрощения работы с правовой политикой Бипиума мы решили сделать включающие привилегии.
RBAC? ABAC. PERM! Новый подход к авторизации в облачных веб-службах и приложениях
Данная статья, преследует цель, рассказать о новом походе к авторизации в облачных решениях, в основе которого лежит использование интерпретируемого языка определения политики управления доступом — который называется языком моделирования PERM (PML). Данный язык можно использовать для выражения различных моделей управления доступом, таких как список управления доступом (ACL), управление доступом на основе ролей (RBAC), управление доступом на основе атрибутов (ABAC) и других. А также рассказать о практическом воплощении этого подхода в виде конкретной реализации кросс-языковой библиотеки авторизации Casbin
Прежде чем приступать к рассказу, хотел выразить благодарность ключевому создателю как самого подхода, так и данной библиотеки Casbin, который является одним из исследователей, работающим в Microsoft Research Asia Yang Luo, он так же известен и как создатель еще одной, довольно известной библиотеки Npcap, которая с 2019 года работает под капотом утилиты Wireshark.
Основы авторизации
В своей сути, любой, даже сложный процесс авторизации можно схематично разбить на три компонента:
Это можно изобразить в виде такой функциональной схемы:
Рис.1. Принципиальная схема авторизации.
Casbin
Casbin — это библиотека авторизации, которая позволяет использовать и комбинировать различные модели управления доступом, такие как ACL, RBAC, ABAC и д.р. С точки зрения Принципиальной схемы авторизации показанной на Рис.1 — Casbin выполняет роль Авторизатора.
Рис.2. Принципиальная схема процесса авторизации с помощью Casbin.
Ключевым элементом механизма авторизации с помощью Casbin является Модель политики авторизации. Эта модель может описываться в текстовом файл *.CONF с помощью метамодели PERM (Policy, Effect, Request, Matchers), ну а по сути представляет из себя коллекцию строк с определенным содержанием.
Как же было сказано, PERM — это гибкая метамодель для построения моделей авторизации. Аббревиатура расшифровывающаяся как (Policy — Политика, Effect — Эффект, Request — Запрос, Matchers — Сопостовители). Конкретный экземпляр PERM описанный в файле CONF, описывает, как эти 4 элемента взаимодействуют друг с другом, определяют логику авторизации.
Пример №1. Список контроля доступа (ACL)
Лучше всего понять модель PERM на конкретном примере.
Представим, что мы создали простую CRM систему, которая хранит список клиентов, и хотим внедрить простую систему контроля доступа, чтобы контролировать кто и что может делать с ресурсом Клиент (client). Для этой задачи подходит модель авторизации которая называется Список Контроля Доступа (Access Control List — ACL).
Эту модель можно выразить в виде системных требований, представленных в следующей таблице, где определено, какие действия разрешены или запрещены пользователям с ресурсом client :
| Пользователь/Действие | Создание (client.create) | Чтение (client.read) | Изменение (client.modify) | Удаление (client.delete) |
|---|---|---|---|---|
| Алиса (alice) | да | да | да | да |
| Боб (bob) | нет | да | нет | да |
| Петр (peter) | да | да | да | нет |
Теперь эту модель мы опишем в конфиг файле с именем client_acl_model.conf на основе метамодели PERM, и дальше разберем каждую секцию
Следует обратить внимание, что, прежде всего, поскольку мы не указываем значение атрибута eft ни для одного из вышеперечисленных правил, все наши правила по умолчанию имеют тип allow (разрешено). Во-вторых, мы не должны определять какие-либо deny правила для нашей системы.
Так как именно такую логику обработки правил мы заложили в нашем конфигурационном файле модели.
Следующий шаг — объединить модель политики, правила политики и саму библиотеку Casbin для создания в нашей CRM системы контроля доступа.
Пример №2. Контроль доступа на основе ролей (RBAC)
Наша система авторизации отлично работает для простых сценариев, по ходу увеличения числа пользователей, утомительно каждому из них назначать разрешения, особенно если этих разрешений несколько. Поэтому мы разработали новую версию системы контроля доступа, на базе ролей, показанной на следующей схеме.
Рис.3. Схема ролей доступа (RBAC).
Мы назначаем разные роли разным пользователям. Пользователю bob назначена роль читателя ( reader ), peter является автором ( author ), а alice теперь админ CRM ( admin ).
Затем для каждой роли мы определяем разрешения (вместо того, чтобы спрашивать, какой пользователь что может делать?, как это описано в модели ACL, теперь мы задаемся вопросом какая роль что может делать?). Мы также наследуем одну роль от другой, тем самым наши роли поддерживают транзитивность. На приведенной выше диаграмме мы от читателя наследуем автора, а от автора наследуем администратора, и каждый наследник обладает теми же разрешениями что и родитель и плюс своими собственными.
Исходя из этого дизайна, конфигурационный файл client_rbac_model.conf для нашей новой модели политики будет выглядеть так:
Содержимое файла client_rbac_policy.csv с правилами политики для такой модели будут выглядеть так:
Пример использования в коде приложения не отличается от предыдущего примера c ACL, за исключением путей к файлам модели и правил политики:
Пример №3. Контроль доступа на основе ролей с поддержкой мультитенатности (RBAC with domains/tenants)
По мере дальнейшего развития нашего приложения CRM, им заинтересовались другие компании, и мы добавили в нашу таблицу с клиентами новый столбец — компания, в который записываем имя копании, которой принадлежит этот клиент, и на основании этого значения отображаем каждой компании только принадлежащих ей клиентов, скрывая клиентов других компаний. Bob ушел в другую компанию, и там стал администратором нашей CRM.
Содержимое файла client_rbac_with_domain_policy.csv с правилами политики для такой модели может выглядеть так:
Пример №4. Контроль доступа на базе модели RESTFul
Данная модель поддерживает возможность реализовывать логику авторизации, когда в качестве объектов доступа выступают ресурсы RestAPI интефрейса в формате URI в виде /res/*,/res/:id, а в качестве действий такие методы HTTP как GET,POST,PUT,DELETE.
Данная возможность обеспечивается благодаря использованию встроенных и пользовательских функций и регулярных выражений в разделе [matchers].
Конфигурационный файл в такой модели будет иметь следующий вид (здесь я использую официальный пример из Casbin):
а файл с определением правил политики:
Пример №5. Контроль доступа на базе атрибутов (ABAC)
Идея, заложенная в модели ABAC достаточно проста, и заключается в том, что политики авторизации строятся не на ролях, а на атрибутах субъектов, объектов доступа, атрибутов операций и атрибутов среды (атрибуты ABAC). Наиболее распространен достаточно сложный стандарт языка управления доступом ABAC под названием XACML. По сравнению с ним, модель ABAC реализованная в Casbin достаточно проста: есть возможность использовать структуры или экземпляры классов, вместо строковых значений атрибутов модели.
Здесь, как и в предыдущем примере, я буду использовать официальный пример из документации Casbin.
Вот пример модели политики на базе ABAC:
Можно использовать несколько атрибутов ABAC при сопоставлении, например
Но для более сложных сценариев с использованием ABAC, существует возможность описать правила ABAC в политике Casbin, чтобы не увеличивать многословность логического выражения в секции [matchers] модели.
Это достигается путем введения в модель функциональной конструкции eval() и называется — масштабированием модели.
Пример конфигурации модели политики abac_scale_model.conf с использованием масштабирования
Файл abac_scale_policy.conf с правилами политики:
Ну и в коде это будет выглядеть так:
Резюме
Библиотека Casbin — очень гибкое и универсальное решение для авторизации, благодаря использованию интерпретируемого языка определения политики управления доступом называемый языком моделирования PERM (PML). Она позволяет использовать как существующие, наиболее распространенные модели управления доступом, так и комбинировать их, либо создавать новые.
В основе Casbin лежит интерпретатор модели политики (policy model) описанной с помощью языка PERM, который сопоставляет значения переданные в качестве атрибутов запроса на авторизацию, с правилами политики (policy) полученными из хранилища политик безопасности.
Библиотека реализована для множества существующих наиболее распространенных языков программирования.
Подходы к контролю доступа: RBAC vs. ABAC
Материал из CustisWiki
Евгений Мяченков, наш ведущий разработчик, опубликовал в корпоративном блоге на «Хабрахабре» статью, посвященную вопросу контроля доступа в компании. Какие существуют подходы к контролю доступа? В чем заключаются достоинства и недостатки ролевого подхода? Какие преимущества по сравнению с ним предоставляет подход, основанный на атрибутах? Ответы на эти вопросы — в материале «Подходы к контролю доступа: RBAC vs. ABAC» на сайте.
Содержание
Введение
Когда компания состоит из одного человека, то внутренних секретов в ней нет. Единственному сотруднику доступны любые действия и любая информация.
Если компания успешна и объемы работы растут, то наступает момент, когда один человек перестает справляться. И тогда в компанию нанимаются новые сотрудники.
Но когда число сотрудников в компании увеличивается, появляются другие проблемы, например:
Если не решить эти проблемы, фирма может понести финансовые потери из-за:
Чтобы решить эти проблемы и правильно разграничить доступ, нужно понимать, кто из сотрудников хочет выполнить действие (аутентификация) и может ли он это сделать (авторизация).
Самой сложной является проблема авторизации. Существует несколько подходов к ее решению, но наибольшее распространение на сегодняшний день получил контроль на основе ролей (role-based access control, RBAC).
Role-based access control (RBAC)
Суть подхода заключается в создании ролей, повторяющих бизнес-роли в компании, и присваивание их пользователям. На основе этих ролей проверяется возможность выполнения пользователем того или иного действия.
Если бизнес-правила одномерны и все действия можно разбить по ролям (бухгалтер, менеджер, администратор и т. п.), такого подхода будет достаточно. Тогда одному бизнес-правилу будет соответствовать одна роль.
Но бизнес-правила неизбежно усложняются и становятся многомерными. Это приводит к тому, что одного атрибута (роли) для выражения бизнес-правил становится недостаточно и начинают добавляться другие атрибуты (город, страна, филиал, день недели, владелец, лимит).
Чтобы справиться с этой сложностью, необходимо создавать дополнительные роли, число которых равно числу различных комбинаций всех атрибутов.
После каждого добавления нового значения атрибута придется добавлять новые роли. То есть, если появится филиал «Г», придется добавить новые роли, такие как «Администратор филиала «Г», «Менеджер филиала «Г», «Бухгалтер филиала «Г» и т. п., после чего присвоить всем требуемым сотрудникам новые роли. Все это порождает много рутинного ручного труда.
Кроме этого, появляются и другие проблемы:
А бизнес-правила, в которых используются атрибуты, значения которых заранее не известны и вычисляются в процессе работы, вообще невозможно выразить с помощью ролевой модели.
Существуют также бизнес-правила, которые ограничивают доступ не к действиям, а к данным. Такие бизнес-правила также невозможно выразить с помощью ролевой модели.
Чтобы реализовать поддержку таких бизнес-правил, придется использовать другие инструменты, что только удорожает и усложняет внедрение и сопровождение системы контроля доступа.
Получается, что как только бизнес-правила становятся многомерными или требуют контроля данных, ролевая модель не только не решает текущие проблемы контроля доступа, но и создает новые.
Attribute-based access control (ABAC)
Чтобы справиться с нерешаемыми в рамках RBAC проблемами, был создан другой подход, который основывается на атрибутах.
Основное отличие этого подхода в том, что каждая ситуация оценивается не с точки зрения роли пользователя и действия, которое он хочет совершить, а с точки зрения атрибутов, которые к ним относятся.
Бизнес-правило, по сути, представляет собой набор условий, в которых различные атрибуты должны удовлетворять предъявляемым к ним требованиям.
Можно явно выделить несколько категорий атрибутов.
Для выполнения авторизации значения всех атрибутов берутся в момент проверки прав и сравниваются с ожидаемыми значениями. Выполнение всех условий обеспечивает доступ к ресурсу.
Простые правила описываются простыми условиями.
Многомерные правила в этой модели не становятся более сложными.
При добавлении новых значений атрибутов условия бизнес-правила меняться не будут. То есть если появится филиал «Г», в условиях бизнес-правила ничего менять не придется. Все, что потребуется, — это добавить нужным сотрудникам значение атрибута «Филиал» — «Филиал «Г».
Таким образом, ABAC позволяет избежать проблем, которые появляются в RBAC:
Но самое главное, ABAC позволяет решить проблемы, которые невозможно решить с помощью RBAC, поскольку в этом подходе нет ограничений на сложность бизнес-правил.
Бизнес-правила любой сложности, в том числе с использованием заранее неизвестных атрибутов, не создают новых проблем и просты в сопровождении.
Представления бизнес-правила в виде набора условий удобно использовать для фильтрации данных. Часть условий можно вычислить еще до обращения к ресурсу, а оставшиеся условия становятся фильтром для выбора данных.
Первые три условия можно проверить еще до обращения к данным. А последнее условие можно использовать в качестве предиката для получения только разрешенных данных.
Сравнение ABAC и RBAC
Как видно из сравнения, RBAC хорошо подходит только для реализации простых бизнес-правил. С увеличением сложности правил целесообразность использования RBAC уменьшается из-за растущей стоимости поддержки системы контроля доступа, а начиная с определенного уровня сложности правил этот подход вообще не дает результата.
ABAC, в свою очередь, не ограничивает сложность бизнес-правил. Благодаря более понятному бизнесу и компактному выражению этот подход позволяет не увеличивать стоимость поддержки при реализации более сложных правил, а также дает возможность обеспечивать контроль доступа не только к действиям, но и к данным.
Полезные ссылки
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
RBAC? ABAC. PERM! Новый подход к авторизации в облачных веб-службах и приложениях
Данная статья преследует цель рассказать о новом походе к авторизации в облачных решениях, в основе которого лежит использование интерпретируемого языка определения политики управления доступом — который называется языком моделирования PERM (PML). Данный язык можно использовать для выражения различных моделей управления доступом, таких как список управления доступом (ACL), управление доступом на основе ролей (RBAC), управление доступом на основе атрибутов (ABAC) и других. А также рассказать о практическом воплощении этого подхода в виде конкретной реализации кросс-языковой библиотеки авторизации Casbin
Прежде чем приступать к рассказу, хотел выразить благодарность ключевому создателю как самого подхода, так и данной библиотеки Casbin, который является одним из исследователей, работающим в Microsoft Research Asia Yang Luo, он так же известен и как создатель еще одной, довольно известной библиотеки Npcap, которая с 2019 года работает под капотом утилиты Wireshark.
Основы авторизации
В своей сути, любой, даже сложный процесс авторизации можно схематично разбить на три компонента:
Это можно изобразить в виде такой функциональной схемы:
Рис.1. Принципиальная схема авторизации.
Casbin
Casbin — это библиотека авторизации, которая позволяет использовать и комбинировать различные модели управления доступом, такие как ACL, RBAC, ABAC и д.р. С точки зрения Принципиальной схемы авторизации показанной на Рис.1 — Casbin выполняет роль Авторизатора.
Рис.2. Принципиальная схема процесса авторизации с помощью Casbin.
Ключевым элементом механизма авторизации с помощью Casbin является Модель политики авторизации. Эта модель может описываться в текстовом файл *.CONF с помощью метамодели PERM (Policy, Effect, Request, Matchers), ну а по сути представляет из себя коллекцию строк с определенным содержанием.
Пример №1. Список контроля доступа (ACL)
Лучше всего понять модель PERM на конкретном примере.
Представим, что мы создали простую CRM систему, которая хранит список клиентов, и хотим внедрить простую систему контроля доступа, чтобы контролировать кто и что может делать с ресурсом Клиент (client). Для этой задачи подходит модель авторизации которая называется Список Контроля Доступа (Access Control List — ACL).
Эту модель можно выразить в виде системных требований, представленных в следующей таблице, где определено, какие действия разрешены или запрещены пользователям с ресурсом client :
| Пользователь/Действие | Создание (client.create) | Чтение (client.read) | Изменение (client.modify) | Удаление (client.delete) |
|---|---|---|---|---|
| Алиса (alice) | да | да | да | да |
| Боб (bob) | нет | да | нет | да |
| Петр (peter) | да | да | да | нет |
Теперь эту модель мы опишем в конфиг файле с именем client_acl_model.conf на основе метамодели PERM, и дальше разберем каждую секцию
Следует обратить внимание, что, прежде всего, поскольку мы не указываем значение атрибута eft ни для одного из вышеперечисленных правил, все наши правила по умолчанию имеют тип allow (разрешено). Во-вторых, мы не должны определять какие-либо deny правила для нашей системы.
Так как именно такую логику обработки правил мы заложили в нашем конфигурационном файле модели.
Следующий шаг — объединить модель политики, правила политики и саму библиотеку Casbin для создания в нашей CRM системы контроля доступа.
Пример №2. Контроль доступа на основе ролей (RBAC)
Наша система авторизации отлично работает для простых сценариев, по ходу увеличения числа пользователей, утомительно каждому из них назначать разрешения, особенно если этих разрешений несколько. Поэтому мы разработали новую версию системы контроля доступа, на базе ролей, показанную на следующей схеме.
Рис.3. Схема ролей доступа (RBAC).
Мы назначаем разные роли разным пользователям. Пользователю bob назначена роль читателя ( reader ), peter является автором ( author ), а alice теперь админ CRM ( admin ).
Затем для каждой роли мы определяем разрешения (вместо того, чтобы спрашивать, какой пользователь что может делать?, как это описано в модели ACL, теперь мы задаемся вопросом какая роль что может делать?). Мы также наследуем одну роль от другой, тем самым наши роли поддерживают транзитивность. На приведенной выше диаграмме мы от читателя наследуем автора, а от автора наследуем администратора, и каждый наследник обладает теми же разрешениями что и родитель и плюс своими собственными.
Исходя из этого дизайна, конфигурационный файл client_rbac_model.conf для нашей новой модели политики будет выглядеть так:
Содержимое файла client_rbac_policy.csv с правилами политики для такой модели будут выглядеть так:
Пример использования в коде приложения не отличается от предыдущего примера c ACL, за исключением путей к файлам модели и правил политики:
Пример №3. Контроль доступа на основе ролей с поддержкой мультитенатности (RBAC with domains/tenants)
По мере дальнейшего развития нашего приложения CRM, им заинтересовались другие компании, и мы добавили в нашу таблицу с клиентами новый столбец — компания, в который записываем имя копании, которой принадлежит этот клиент, и на основании этого значения отображаем каждой компании только принадлежащих ей клиентов, скрывая клиентов других компаний. Bob ушел в другую компанию, и там стал администратором нашей CRM.
Содержимое файла client_rbac_with_domain_policy.csv с правилами политики для такой модели может выглядеть так:
Пример №4. Контроль доступа на базе модели RESTFul
Данная модель поддерживает возможность реализовывать логику авторизации, когда в качестве объектов доступа выступают ресурсы RestAPI интефрейса в формате URI в виде /res/*,/res/:id, а в качестве действий такие методы HTTP как GET,POST,PUT,DELETE.
Данная возможность обеспечивается благодаря использованию встроенных и пользовательских функций и регулярных выражений в разделе [matchers].
Конфигурационный файл в такой модели будет иметь следующий вид (здесь я использую официальный пример из Casbin):
а файл с определением правил политики:
Пример №5. Контроль доступа на базе атрибутов (ABAC)
Идея, заложенная в модели ABAC достаточно проста, и заключается в том, что политики авторизации строятся не на ролях, а на атрибутах субъектов, объектов доступа, атрибутов операций и атрибутов среды (атрибуты ABAC). Наиболее распространен достаточно сложный стандарт языка управления доступом ABAC под названием XACML. По сравнению с ним, модель ABAC реализованная в Casbin достаточно проста: есть возможность использовать структуры или экземпляры классов, вместо строковых значений атрибутов модели.
Здесь, как и в предыдущем примере, я буду использовать официальный пример из документации Casbin.
Вот пример модели политики на базе ABAC:
Можно использовать несколько атрибутов ABAC при сопоставлении, например
Но для более сложных сценариев с использованием ABAC, существует возможность описать правила ABAC в политике Casbin, чтобы не увеличивать многословность логического выражения в секции [matchers] модели.
Это достигается путем введения в модель функциональной конструкции eval() и называется — масштабированием модели.
Пример конфигурации модели политики abac_scale_model.conf с использованием масштабирования
Файл abac_scale_policy.conf с правилами политики:
Ну и в коде это будет выглядеть так:
Резюме
Библиотека Casbin — очень гибкое и универсальное решение для авторизации, благодаря использованию интерпретируемого языка определения политики управления доступом называемый языком моделирования PERM (PML). Она позволяет использовать как существующие, наиболее распространенные модели управления доступом, так и комбинировать их, либо создавать новые.
В основе Casbin лежит интерпретатор модели политики (policy model) описанной с помощью языка PERM, который сопоставляет значения переданные в качестве атрибутов запроса на авторизацию, с правилами политики (policy) полученными из хранилища политик безопасности.
Библиотека реализована для множества существующих наиболее распространенных языков программирования.