Модели политик в интерфейсе Системы¶

Различные политики объединяет их общая модель. Модели политик заранее заведены в Системе, пользователю нужно только добавить к ним зависимые политики Casbin. Для этого необходимо выполнить следующие действия:

1. В разделе Модели открыть нужную модель политик двойным нажатием ЛКМ на ее строку.

В Системе доступны две модели политик: API (проверка прав на уровне вызова HTTP-запросов) и DATA (проверка прав на уровне конкретных объектов внутри Системы).

Карточка модели политик содержит общие атрибуты в блоке Общие данные и атрибуты в блоке Модель Casbin, недоступные для редактирования.

Поля блока Модель Casbin в карточке модели API соответствуют модели в редакторе Casbin.

Маппинг полей модели Casbin для API

Модель Casbin в редакторе	Модель Casbin в интерфейсе Системы
request_definition	Параметры, определяющие структуру запроса: - subject – атрибуты субъекта; - endpoint – данные об эндпоинте, к которому будет применяться проверка доступа: «/api/v1/documents»; - metod – данные о методе эндпоинта, например, POST, GET и т.д.
policy_definition	Параметры, определяющие структуру политики: - subject – атрибуты субъекта; - endpoint – данные об эндпоинте, к которому будет применяться проверка доступа: «/api/v1/documents»; - metod – данные о методе эндпоинта, например, POST, GET и т.д.; - effect – запрещающий или разрешающий эффект (allow или deny); - environment – дополнительные параметры, которые могут применяться при проверке, например, текущее время, ip-адрес и т.д. (не используется и указывается как «true» в политике)
role_ definition	Ролевое определение для определений отношения наследования ролей
policy_effect	Эффект применения политики для получения конечного результата доступа («allow» или «deny») при проверке нескольких политик
matchers	Выражение проверки: § eval(p.sub), eval(p.env) – условие по вычислению субъекта/дополнительных параметров; § keyMatch3(r.ep, p.ep) – функция по вычислению эндпоинта; § regexMatch(r.met, p.met) – регулярное выражение для метода

Поля блока Модель Casbin в карточке модели DATA соответствуют модели в редакторе.

Маппинг полей модели Casbin для DATA

Модель Casbin в редакторе	Модель Casbin в интерфейсе Системы
request_definition	Параметры, определяющие структуру запроса: - subject – атрибуты субъекта; - object – объект данных, к которому будет проверяться проверка доступа, например, документ; - action – применяемое действие к объекту, например, create, delete, read; - environment – дополнительные параметры, которые могут применяться при проверке, например, текущее время, IP-адрес и т.д.
policy_definition	Параметры, определяющие структуру политики: - subject – атрибуты субъекта; - object – объект данных, к которому будет проверяться проверка доступа, например, документ; - action – применяемое действие к объекту, например, create, delete, read; - effect – запрещающий или разрешающий эффект («allow» или «deny»); - environment – дополнительные параметры, которые могут применяться при проверке, например, текущее время (не используется и указывается как «true» в политике)
role_ definition	Ролевое определение для определений отношения наследования ролей
policy_effect	Эффект применения политики для получения конечного результата доступа («allow» или «deny») при проверке нескольких политик
matchers	Выражение проверки: - eval(p.sub) && eval(p.obj) && eval(p.env) – условие по вычислению субъекта/объекта/дополнительных параметров; - regexMatch(r.act, p.act) – регулярное выражение для действия

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

В блоке Зависимые политики Casbin можно добавить одну или несколько политик доступа, которые после создания будут закреплены за текущей моделью.

2. В блоке Зависимые политики Casbin нажать кнопку .

3. В открывшемся модальном окне заполнить поля.

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

Тип политики указывается как «p».

В поле Параметр 1 необходимо вручную прописать правило для ролей или логинов пользователей, которым в рамках данной политики будет разрешен доступ. Пример заполнения поля: "role_analytic" in (r.sub.roles), которое является условием, при котором роль «Аналитик» должна присутствовать в списке его ролей «subject roles». Список ролей пользователя Система получает из токена. Рекомендуется создавать отдельные политики для каждой роли/логина пользователей.

В поле Параметр 2 требуется указать правило для объекта. Для типа модели DATA правило может включать в себя условия, распространяющиеся, например, на класс объекта, его атрибуты или создателя объекта. Например:

• «r.obj.createdBy == "admin"» предоставляет доступ к объектам, созданным пользователем «admin».
• «(r.obj.createdBy == r.sub.login) && (r.obj.isPrivateCopy == true)» предоставляет доступ к рабочей копии документа для автора.

Данный пример работает только в методах, возвращающих отдельные объекты. Cложные условия при получении списка не поддерживаются.

• «r.obj.className == "compound_data"» предоставляет доступ к классу объекта «compound_data».

Для предоставления права на обращение к REST API в данном поле необходимо указать внутренний эндпоинт, по которому будет выполняться запрос. Например, «/dh-configurations-service/api/configurations». Допускается наименование сервиса заменять символом , например, «//api/v1/preview». В таком случае принадлежность к сервису Системой будет определяться исходя из значения в поле Сервис. Для предоставления доступа ко всем эндпоинтам сервиса поле Параметр 2 можно заполнить значением «/*».

В поле Параметр 3 прописать все необходимые действия. Таких действий может быть несколько, они указываются в скобках и разделяются логическим элементом |. Пример заполнения поля для типа модели DATA: «(create)|(update)|(delete)». Для предоставления права на обращение к REST API в данном поле необходимо указать единичный метод (например, «GET») или перечислить методы, разделяя их логическим элементом |. Например, «(POST)|(GET)». Для всех моделей можно использовать значение «.*», которое служит обозначением всех возможных действий или методов. Это подстановочный знак, который позволяет определить общие правила без указания конкретных значений.

В поле Параметр 4 указать значение «allow» или «deny». Указывая, например, значение «allow», будет действовать разрешительная политика, где запрещено все, кроме того, что было разрешено посредством создания политики. При значении «deny» действует запретительная политика.

Поле Параметр 5 может содержать значение «true». Поле Параметр 6 заполнять не требуется.

Создаваемую политику можно сразу активировать, включив тумблер Активно. Политика начинает действовать только после ее активации.

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

4. Нажать кнопку [Создать].

Созданная политика доступа появится в блоке Зависимые политики Casbin. Примеры таких политик представлены в таблице:

Примеры использования политик

Пример использования	Описание
p = "ldm_user" in (r.sub.roles), r.obj.className != "", allow, true	Предоставляет роли «ldm_user» доступ по слою DATA для указанного сервиса
p = "role_analytic" in (r.sub.roles), (r.obj.createdBy == r.sub.login) && (r.obj.isPrivateCopy == true), allow	Предоставляет роли «Аналитик» доступ к рабочей копии документа
p = r.sub.login == "usertest", r.obj.className == "testdoc", .*, allow, true	Предоставляет разрешение на все действия с классом документа «testdoc» для пользователя с логином «usertest»
p = r.sub.login == "usertest", (r.obj.className == "Contract") && (r.obj.data.contractTotal <= 100), read, allow, true	Предоставляет пользователю с логином «usertest» возможность просматривать атрибуты объектов с классом «Contract» и значением в параметре «contractTotal» меньше или равным 100
p = "role_analytic" in (r.sub.roles), r.obj.taskState == "COMPLETED", read, deny	Запрещает роли «Аналитик» просматривать задачи в статусе «Выполнено»
p = "admin" in (r.sub.roles), /*, allow	Предоставляет роли «admin» доступ по слою API ко всем методам указанного сервиса, например, сервиса «Права доступа»
p = r.sub.login == "usertest", (r.obj.className == "Contract"), download_content, allow, true	Предоставляет пользователю с логином «usertest» возможность скачивать файл документов с классом «Contract»
p = r.sub.login == "usertest", (r.obj.className == "Contract"), delete, allow, true	Предоставляет пользователю с логином «usertest» возможность удалять документы с классом «Contract»

Для корректной авторизации пользователя в Системе в первую очередь требуются политики по слою API для сервисов «Права доступа» и «Настройки пользователя»: p = "user" in (r.sub.roles), /*, allow с указанием сервиса в форме создания. После этого аналогичным образом необходимо создать политики по слою API для других сервисов, в которых планируются работы.

Также обязательным действием в рамках работы с политиками является предоставление API прав на получение списка существующих ролей всем пользователям. Для этого рекомендуется завести в Keycloak общую для пользователей роль или группу, после чего в сервисе «Права доступа» настроить политику для запроса «POST /dh-accessrights-service/api/v1/dha/access/roles».

Помимо стандартных политик в Системе существует возможность настройки доступа к ACL-объектам. Такая политика предоставляет доступ ко всем ACL-объектам с соответствующими правами и может выглядеть следующим образом: p = true, checkAcl(r.obj.acl\, r.sub\, r.act), allow.

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

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