Understanding How Casbin Matching Works in Detail

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

Вступ до RBAC

RBAC - це метод обмеження доступу до ресурсів на основі ролей, які мають особи. Щоб краще зрозуміти, як працює ієрархічний RBAC, давайте розглянемо систему RBAC Azure в наступному розділі, а потім спробуємо реалізувати подібну систему.

Розуміння ієрархічного RBAC Azure

Ієрархія Azure

В Azure є роль під назвою Owner для всіх ресурсів. Припустимо, якщо мені призначено роль Owner на рівні підписки, це означає, що я є Owner всіх груп ресурсів та ресурсів під цією підпискою. Якщо у мене є роль Owner на рівні групи ресурсів, то я є Owner всіх ресурсів під цією групою ресурсів.

Це зображення показує, що у мене є доступ Owner на рівні підписки. Власник підписки

Коли я перевіряю IAM групи ресурсів під цією підпискою, ви можете побачити, що я успадкував доступ Owner від підписки. Власник 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

request_definition - це шаблон запиту системи. Наприклад, запит alice, write, data1 можна інтерпретувати як "Чи може суб'єкт Аліса виконати дію 'write' на об'єкті 'data1'?".
policy_definition - це шаблон призначення системи. Наприклад, створивши політику alice, write, data1, ви призначаєте дозвіл суб'єкту Алісі виконувати дію '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, політики та зіставлення запитів

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, політики та відповідності запитів

rbac

Таблиця g - Відображення ролі до дії має графічне відображення ролі до дії. Цей граф можна закодувати як список ребер, як показано в політиці, що є загальноприйнятим способом представлення графа:

g, reader, read
g, owner, read
g, owner, write

інформація

p вказує на звичайну політику, яку можна порівняти за допомогою оператора ==. g - це функція порівняння на основі графа. Ви можете визначити кілька компараторів графів, додавши числовий суфікс, як g, g2, g3, ... і так далі.

Що таке Ієрархічний RBAC?

У Ієрархічному RBAC є більше ніж один тип ресурсів, і між типами ресурсів існує відношення успадкування. Наприклад, "subscription" - це один тип, а "resourceGroup" - інший тип. sub1 типу Subscription може містити кілька resourceGroups (rg1, rg2) типу ResourceGroup.

Аналогічно до ієрархії ресурсів, буде два типи ролей та дій: ролі та дії для Subscription, і ролі та дії для ResourceGroup. Існує довільне відношення між роллю Subscription та роллю ResourceGroup. Наприклад, розглянемо роль Subscription sub-owner. Ця роль успадковується роллю ResourceGroup rg-owner, що означає, що якщо мені призначено роль sub-owner на Subscription sub1, то я автоматично також отримую роль rg-owner на rg1 та rg2.

Визначення моделі

Давайте розглянемо простий приклад моделі Ієрархічного 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, політики та відповідності запитів

hrbac

Таблиця g - Відображення ролі до (Дія, Роль) має графічне відображення ролі до дії, відображення ролі. Цей граф можна закодувати як список ребер, як показано в політиці, що є загальноприйнятим способом представлення графа:

// 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 до RG має графічне відображення підписки до resourceGroup:

// 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.