Тестирование модели в редакторе Casbin

Из Casbin, куда загружена модель, включающая в себя необходимое число политик для проверки, в сервис «Права доступа» приходит запрос с набором параметров. Данные параметры проходят проверку на соответствие модели, после чего применяются или не применяются определенные ограничения в зависимости от результатов проверки.

Перед работой с моделью политик в интерфейсе Системы рекомендуется ее протестировать в редакторе Casbin, который расположен по адресу: https://casbin.org/editor.

img

В редакторе Casbin в верхнем блоке слева располагается модель, справа политика доступа; в нижнем блоке – пример запроса и результат применения.

Модель определяет структуру запроса (request_definition), структуру политики (policy_definition), структуру эффекта применения политики (policy_effect), а также правила, по которым производится расчет политики и определяется их результат (matchers).

В качестве примера можно рассмотреть модель ниже:

Модель:

[request_definition]

r = sub, obj, act


[policy_definition]

p = sub_rule, obj, act, eft


[role_definition]

g=_, _


[policy_effect]

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


[matchers]

m = eval(p.sub_rule) && regexMatch(r.act, p.act)

Согласно описанной выше модели определены:

  1. Запрос (request_definition) состоит из трех параметров: sub (информация о пользователе), obj (информация об объекте, к которому требуется доступ), act (действие (для доступа к данным) или HTTP метод (для доступа к API), которое пользователь хочет совершить над объектом).

  2. Политика (policy_definition) состоит из трех параметров: sub_rule (правило для пользователей), obj (описание объекта (условие или атрибут), при котором открывается или закрывается доступ), act (действие или список действий (для доступа к данным) или HTTP метод(ы) (для доступа к API), eft (возможные значения allow или deny), при отсутствии параметра в политике по умолчанию – allow).

  3. Ролевое определение (role_definition) – необязательный раздел. Не заполняется.

  4. Эффект применения политики (policy_effect) – если по результатам сверки запроса и политик вернется хотя бы один allow, то результат проверки – true, иначе false.

  5. Выражение, по которому выполняется наложение условий для вычисления результата проверки (matchers). В примере выше для вычисления результата проверки доступа складываются значение, описанное в поле p.sub_rule (см. policy_definition) и результат проверки совпадения значения act из запроса и act из политики.

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

Модель:

r = sub, obj, act

p = sub_rule, obj, act, eft

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

g=_, _

m = eval(p.sub_rule) && keyMatch3(r.obj, p.obj) && regexMatch(r.act, p.act)

Политика:

p.sub_rule = Admin in (r.sub.roles) # Политика распространяется на пользователей с ролью Admin

p.obj = /dh-documents-service/* # Политика распространяется на все методы, которые начинаются на /dh-documents-service/

p.act = (POST)|(GET)|(PUT) # Политика распространяется только на HTTP методы POST, GET, PUT

p.eft = allow #разрешено

Запрос 1:

Admin, /dh-documents-service/api/v1/objects, POST

Запрос 2:

Admin, /dh-documents-service/api/v1/objects, GET

Запрос 3:

Admin, /dh-documents-service/api/v1/objects, PUT

Запрос 4:

Admin, /dh-documents-service/api/v1/objects, DELETE

Ожидаемый результат проверки этих запросов:

  • true;
  • true;
  • true;
  • false.

На рисунке представлены результаты проверки в редакторе Casbin.

img

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

Модель:

r = sub, obj, act

p = sub, obj, act

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

m = eval(p.sub) && eval(p.obj) && eval(p.act)

Политика:

p.sub_rule = 'user1' in (r.sub.roles) # Политика распространяется на пользователей c ролью user1

p.obj = ('EconomystDocs' in (r.obj.objectClass)) || ('FinancialDocs' in (r.obj.objectClass)) # Политика распространяется на документы, которые входят в классы документов EconomystDocs и FinancialDocs

p.act = (r.act == 'update')||(r.act == 'browse') # Политика распространяется только на действия: изменить, просмотреть список

Запрос 1:

{"login": "Abramova", "roles":["user1", "user99", "user98"]}, {"objectClass":["EconomystDocs"]}, browse

Запрос 2:

{"login": "Abramova", "roles":["user1", "user99", "user98"]}, {"objectClass":["EconomystDocs"]}, create

Запрос 3:

{"login": "Sidorov", "roles":["user1", "user99", "user98"]}, {"objectClass":["FinancialDocs"]}, update

Запрос 4:

{"login": "Sidorov", "roles":["user2", "user99", "user98"]}, {"objectClass":["FinancialDocs"]}, update

Ожидаемый результат проверки этих запросов:

  • true;
  • false;
  • true;
  • false.

На рисунке представлен результат проверки в редакторе Casbin.

img

Для более детального изучения работы Casbin рекомендуется обратиться к его официальной документации, расположенной по адресу: https://casbin.org/docs/overview. Документация для скачивания в pdf формате расположена по адресу: https://casbin.org/pdf.