Перейти к основному контенту

Understanding How Casbin Matching Works in Detail

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

Введение в RBAC

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

Понимание иерархического RBAC Azure

Иерархия Azure

В Azure для всех ресурсов есть роль под названием Владелец. Предположим, если мне назначена роль Владелец на уровне подписки, это означает, что я являюсь Владельцем всех групп ресурсов и ресурсов под этой подпиской. Если у меня есть роль Владелец на уровне группы ресурсов, то я являюсь Владельцем всех ресурсов в этой группе ресурсов.

На этом изображении показано, что у меня есть доступ Владельца на уровне подписки. Владелец подписки

Когда я проверяю IAM группы ресурсов под этой подпиской, вы можете видеть, что я унаследовал доступ Владельца от подписки. Владелец RG

Итак, вот как иерархический 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
  1. request_definition - это шаблон запроса системы. Например, запрос alice, write, data1 можно интерпретировать как "Может ли субъект Alice выполнить действие 'write' над объектом 'data1'?".

  2. policy_definition - это шаблон назначения системы. Например, создав политику alice, write, data1, вы предоставляете разрешение субъекту Alice на выполнение действия 'write' над объектом 'data1'.

  3. policy_effect определяет эффект политики.

  4. В разделе 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, политики и сопоставления запросов

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
  1. 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, политики и сопоставления запросов

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)
  1. 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, политики и сопоставления запросов

hrbac

Таблица 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

Визуальное представление сопоставления субъектов

hrbac-sub-match

Визуальное представление сопоставления действий

hrbac-act-match

Визуальное представление сопоставления объектов

hrbac-obj-match

инфо

Когда запрос отправляется в Casbin, это сопоставление происходит для всех политик. Если хотя бы одна политика совпадает, то результат запроса будет истинным. Если ни одна политика не совпадает с запросом, то результат будет ложным.

Заключение

В этом уроке мы узнали, как работают различные модели авторизации и как их можно моделировать с помощью Casbin. Во второй части этого урока мы реализуем это в демонстрационном приложении Spring Boot и обеспечим безопасность API с помощью Casbin.