ACL, RBAC, ABAC

Привет, разработчики 👋. Авторизация - ключевая часть каждой созданной нами системы, и Casbin - это одно из распространенных имен, которые мы слышим на всех языках для авторизации.

В настоящее время Casbin поддерживает Golang, Java, C / C ++, Node.js, Javascript, PHP, Laravel, Python, .NET (C #), Delphi, Rust, Ruby, Swift (Objective-C), Lua (OpenResty), Дарт (Флаттер) и Эликсир.

В этой статье моя цель - продемонстрировать работу casbin и его различные доступные конфигурации моделей в простой и понятной схеме.

Если вы уже знаете основы casbin и вам просто нужен поток реализации casbin в golang, вы можете проверить другую мою статью об авторизации в проектах Golang с использованием Casbin.



Рабочий процесс Casbin

Прежде чем переходить к различным конфигурациям модели, давайте попробуем понять рабочий процесс casbin с помощью простой обзорной схемы, как показано ниже.

Я разделил общий рабочий процесс на два этапа, а именно: Конфигурация и Реализация.

Фаза конфигурации

На этом этапе все зависит от конфигураций.

Шаг 1 (Модель)

Здесь мы настраиваем модель в соответствии с нашими требованиями. Мы используем файл CONF (расширение файла .conf), чтобы абстрагироваться от конфигурации нашей модели. Эта конфигурация основана на метамодели PERM (Политика, Эффект, Запрос, Сопоставители) (подробности будут описаны ниже с примерами).

На приведенной выше диаграмме я взял базовую и простейшую модель в Casbin, то есть ACL (будет обсуждаться позже).

Шаг 2 (Политика)

Здесь мы определяем такие политики, как who can do what и who has what permissions

Базовый синтаксис политики

p= sub, obj, act, eft

Этот синтаксис можно прочитать так: кто (sub) может / не может (разрешить / запретить) что-то (действие ) на каком-то ресурсе (obj)

Здесь eft может быть либо allow, либо deny. Если он не включен, значение по умолчанию - allow.

На приведенной выше диаграмме в соответствии с политиками, определенными

  1. У Джона есть разрешение на чтение ЗАПИСИ 1
  2. У Джона нет разрешения на запись RECORD1
  3. У Гарри есть разрешение на чтение ЗАПИСИ 1
  4. У Гарри есть разрешение на запись RECORD1.

Фаза реализации

Этот этап посвящен реализации в соответствии с конфигурациями модели [Шаг 1] и перечисленными политиками [Шаг 2]

Шаг 3 (Запрос)

Это сценарий реального времени, когда пользователь пытается получить доступ или выполнить желаемые действия на каком-либо ресурсе.

На приведенной выше диаграмме согласно входящему запросу

  1. Джон хочет прочитать ЗАПИСЬ1
  2. Джон хочет писать на RECORD1

Результат исполнения

Это сценарий реального времени, когда принимается решение, разрешить ли пользователю доступ к данному ресурсу или выполнять его желаемые действия.

Step4 (совпадение)

Первый шаг в обеспечении результатов - сопоставление запроса со списком политик. В приведенном выше примере у нас есть следующее выражение сопоставления, которое просто гарантирует, что субъект, объект и действие в запросе должны соответствовать тем, что в правиле политики.

m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

Шаг 5 (действие политики)

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

e = some(where (p.eft == allow))

После этих двух шагов casbin обеспечит результат как

  1. Джону разрешено читать ЗАПИСЬ1 ✔️
  2. Джону отказано в записи на RECORD1 ❌

Углубляясь

Я надеюсь, что представленный выше простой обзор поможет в некоторой степени визуализировать рабочий процесс Casbin. Теперь мы увидим разные способы настройки модели [Шаг 1 согласно приведенной выше диаграмме]

Типы контроля доступа

Список контроля доступа (ACL)

Это самый простой механизм контроля доступа. Здесь перечислены 1–1 сопоставление разрешений каждого пользователя на данном ресурсе.

If there are total three users;user1,user2,user3. There is a permissions defined for each users individually.
user1 can only read record1
user2 can only write record1
user3 can read and write record1

Конфигурация модели Casbin

  • r = sub, obj, act предоставляет информацию о том, кто (подчиненный) и что хочет делать (действовать) на каком-либо ресурсе (obj).
  • p = sub, obj, act дает информацию о том, кто (подчиненный) может делать (действовать) на каком-либо ресурсе (obj).

Эффект политики

  • e = some(where (p.eft == allow)) означает, что у пользователя есть разрешение до тех пор, пока существует одна соответствующая политика, которая позволяет ему это делать.

Некоторые другие варианты

  • e = !some(where (p.eft == deny)) означает, что у пользователя есть разрешение до тех пор, пока нет соответствующей политики, запрещающей ему это делать.
  • e = some(where (p.eft == allow)) && !some(where (p.eft == deny)) означает, что у пользователя есть разрешение, пока существует одна соответствующая политика и нет согласованной политики отказа.

Сопоставители

m = r.sub == p.sub && r.obj == p.obj && r.act == p.act определяет рабочий процесс авторизации. Он проверяет, может ли пользователь выполнить данное действие (он пытается выполнить) на данном ресурсе. Другими словами, оценивает правило политики относительно запроса. Здесь, в указанном выше сопоставлении, субъект, объект и действие в запросе должны совпадать с таковыми в правиле политики, чтобы предоставить доступ пользователю.

Контроль доступа на основе ролей (RBAC)

Это решает приведенное выше отображение 1–1, которое требовалось раньше. Теперь мы распределяем пользователей по ролям и назначаем разрешения роли, а не отдельным пользователям.

If there are total three users;user1,user2,user3 and two role;admin and user. In this case we define permission to the role not to the individual user.
user1,user2 has role user
user3 has role admin
user can only read record1 (user1,user2)
admin can read and write write record1 (user3)

Конфигурация модели Casbin

То же, что и предыдущее, но мы добавили здесь параметр g

g = _, _ определяет роль пользователя.

// user1 is a admin and admin can write record1 which means user1 can write record1
p, admin, record1, write
g, user1, admin

RBAC с ролями ресурсов

Подобно тому, как мы сгруппировали пользователей по ролям, мы также можем группировать ресурсы и назначать их вместо того, чтобы назначать один ресурс за раз.

Здесь мы добавили здесь параметр g2

g2 = _, _ определяет роль ресурса.

// record1 and record2 is grouped to record and user1 can write record which means user1 can write record1 and record2 both
p, user1, record, write
g2, record1, record
g2, record2, record

RBAC с доменами (арендаторами)

Это еще одна версия RBAC, которая может быть необходима, когда в системе несколько клиентов, а у пользователя разные роли в другом клиенте.

//user1 is admin in tenant1 and user2 is admin in tenant2. Admin in tenant1(which means user1) can read and write data1. Similarly Admin in tenant2(which means user2) can read and write data2. This also means user1 has no permission to read/write data2 and viceversa.
p, admin, tenant1, data1, read
p, admin, tenant1, data1, write
p, admin, tenant2, data2, read
p, admin, tenant2, data2, write
g, user1, admin, tenant1
g, user2, admin, tenant2

Атрибутный контроль доступа (ABAC)

Если ваш вариант использования не может быть решен ни одной из вышеперечисленных моделей, существует другая модель, которая обеспечивает более детальный поиск / сопоставление. Оценка выполняется на основе определенных атрибутов (например, атрибутов пользователя). В случае casbin атрибутами могут быть свойства субъекта, объекта или действий.

Например, система RBAC предоставляет доступ всем менеджерам, но политика ABAC будет предоставлять доступ только менеджерам, которые находятся в финансовом отделе.

Эта модальная конфигурация просто проверяет, является ли запрашивающий пользователь владельцем этого запрошенного объекта.

//If Following Request
user1, {Owner:"user1"}
user1, {Owner:"user2"}
//Mapping the request to sub,obj,act
sub= user1
obj= {Owner:"user1"}
//Matchers we have
r.sub == r.obj.Owner
user1 == user1 // 1st Request is given access
user1 == user2 // 2nd Request is not given access as he is not the                   .                 owner of that resource

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

ЗАКЛЮЧЕНИЕ

Это конец статьи в понимании casbin. Мы продолжим этот путь от понимания casbin до реализации casbin в голанге в следующей статье. Надеюсь, эта статья помогла моим читателям. Любые предложения будут очень ценными. Счастливого кодирования ☺.