Understanding How Casbin Matching Works in Detail
В этом посте я объясню дизайн и реализацию RBAC с использованием библиотеки Casbin. Для SaaS-платформы, работающей с несколькими иерархиями ресурсов и ролями, наследующими разрешения от более высоких уровней, Casbin предлагает производительную альтернативу для рассмотрения.
Введение в RBAC
RBAC - это метод ограничения доступа к ресурсам на основе ролей, которые занимают отдельные лица. Чтобы лучше понять, как работает иерархический RBAC, давайте рассмотрим систему RBAC Azure в следующем разделе, а затем попробуем реализовать подобную систему.
Понимание иерархического RBAC Azure
В Azure для всех ресурсов есть роль под названием Владелец. Предположим, если мне назначена роль Владелец на уровне подписки, это означает, что я являюсь Владельцем всех групп ресурсов и ресурсов под этой подпиской. Если у меня есть роль Владелец на уровне группы ресурсов, то я являюсь Владельцем всех ресурсов в этой группе ресурсов.
На этом изображении показано, что у меня есть доступ Владельца на уровне подписки.
Когда я проверяю IAM группы ресурсов под этой подпиской, вы можете видеть, что я унаследовал доступ Владельца от подписки.
Итак, вот как иерархический RBAC в Azure. Большинство корпоративного программного обеспечения использует иерархический RBAC из-за иерархической природы уровней ресурсов. В этом уроке мы попробуем реализовать подобную систему с использованием Casbin.
Как работает Casbin?
Прежде чем приступить к реализации, важно понять, что такое Casbin и как он функционирует на высоком уровне. Это понимание необходимо, потому что каждая система управления доступом на основе ролей (RBAC) может варьироваться в зависимости от конкретных требований. Осознавая принципы работы Casbin, мы можем эффективно настроить модель.
Что такое ACL?
ACL означает список контроля доступа. Это метод, при котором пользователи сопоставляются с действиями, а действия - с ресурсами.
Определение модели
Рассмотрим простой пример модели ACL.
[request_definition]
r = sub, act, obj
[policy_definition]
p = sub, act, obj
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
request_definition - это шаблон запроса системы. Например, запрос
alice, write, data1
можно интерпретировать как "Может ли субъект Alice выполнить действие 'write' над объектом 'data1'?".policy_definition - это шаблон назначения системы. Например, создав политику
alice, write, data1
, вы предоставляете разрешение субъекту Alice на выполнение действия 'write' над объектом 'data1'.policy_effect определяет эффект политики.
В разделе matchers запрос сопоставляется с политикой с использованием условий
r.sub == p.sub && r.obj == p.obj && r.act == p.act
.
Теперь давайте протестируем модель в редакторе Casbin
Откройте редактор и вставьте вышеуказанную модель в редактор моделей.
Вставьте следующее в редактор политик:
p, alice, read, data1
p, bob, write, data2
и следующее в редактор запросов:
alice, read, data1
Результат будет следующим:
true
Визуальное представление модели ACL, политики и сопоставления запросов
Что такое RBAC?
RBAC означает контроль доступа на основе ролей. В RBAC пользователю назначается роль для ресурса, и роль может содержать произвольные действия. Затем запрос проверяет, есть ли у пользователя разрешение на выполнение действия над ресурсом.
Определение модели
Рассмотрим простую модель RBAC:
[request_definition]
r = sub, act, obj
[policy_definition]
p = sub, act, obj
[role_definition]
g = _, _
g2 = _, _
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = r.sub == p.sub && g(p.act, r.act) && r.obj == p.obj
- role_definition - это конструктор отношений графа, который использует граф для сравнения объекта запроса с объектом политики.
Теперь давайте протестируем модель в редакторе Casbin
Откройте редактор и вставьте вышеуказанную модель в редактор моделей.
Вставьте следующее в редактор политик:
p, alice, reader, data1
p, bob, owner, data2
g, reader, read
g, owner, read
g, owner, write
и следующее в редактор запросов:
alice, read, data1
alice, write, data1
bob, write, data2
bob, read, data2
bob, write, data1
Результат будет следующим:
true
false
true
true
false
Визуальное представление модели RBAC, политики и сопоставления запросов
Таблица g - Role to action mapping имеет графическое отображение роли к действию. Этот граф можно закодировать в виде списка ребер, как показано в политике, что является общим способом представления графа:
g, reader, read
g, owner, read
g, owner, write
p указывает на обычную политику, которую можно сравнить с использованием оператора ==. g - это функция сравнения на основе графа. Вы можете определить несколько сравнителей графа, добавив числовой суффикс, например g, g2, g3, ... и так далее.
Что такое иерархический RBAC?
В иерархическом RBAC существует более одного типа ресурсов, и между типами ресурсов существует отношение наследования. Например, "подписка" - это один тип, а "группа ресурсов" - другой тип. Подписка типа Subscription может содержать несколько групп ресурсов (rg1, rg2) типа ResourceGroup.
Аналогично иерархии ресурсов, будут два типа ролей и действий: роли и действия подписки, а также роли и действия группы ресурсов. Между ролью подписки и ролью группы ресурсов существует произвольное отношение. Например, рассмотрим роль подписки sub-owner. Эта роль наследуется ролью группы ресурсов rg-owner, что означает, что если мне назначена роль sub-owner на подписке sub1, то я автоматически получаю роль rg-owner на rg1 и rg2.
Определение модели
Рассмотрим простой пример модели Hierarchical RBAC:
[request_definition]
r = sub, act, obj
[policy_definition]
p = sub, act, obj
[role_definition]
g = _, _
g2 = _, _
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = r.sub == p.sub && g(p.act, r.act) && g2(p.obj, r.obj)
- role_definition - это конструктор отношений графа, который использует граф для сравнения объекта запроса с объектом политики.
Теперь давайте протестируем модель в редакторе Casbin
Откройте редактор и вставьте вышеуказанную модель в редактор моделей.
Вставьте следующее в редактор политик:
p, alice, sub-reader, sub1
p, bob, rg-owner, rg2
// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write
// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write
// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner
// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2
И вставьте следующее в редактор запросов:
alice, rg-read, rg1
Результат будет следующим:
true
Визуальное представление модели RBAC, политики и сопоставления запросов
Таблица g - Role to (Action, Role) Mapping имеет графическое отображение роли к действию, отображение роли. Этот граф можно закодировать в виде списка ребер, как показано в политике, что является общим способом представления графа:
// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write
// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write
// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner
Таблица g2 - Sub to RG Mapping имеет графическое отображение подписки на группу ресурсов:
// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2
Визуальное представление сопоставления субъектов
Визуальное представление сопоставления действий
Визуальное представление сопоставления объектов
Когда запрос отправляется в Casbin, это сопоставление происходит для всех политик. Если хотя бы одна политика совпадает, то результат запроса будет истинным. Если ни одна политика не совпадает с запросом, то результат будет ложным.
Заключение
В этом уроке мы узнали, как работают различные модели авторизации и как их можно моделировать с помощью Casbin. Во второй части этого урока мы реализуем это в демонстрационном приложении Spring Boot и обеспечим безопасность API с помощью Casbin.