После написания предыдущей статьи по языку PERM и библиотеке Casbin, возникли вопросы. Причем не у одного человека, и я хотел ответить сначала в комментарии, но понял, что объем материала выходит за рамки обычного комментария, поэтому изложу этот ответ в виде отдельной статьи.
Я долго не мог понять ту конкретную конструкцию, которая сидела в голове у вопрошающих, но в конечном итоге после уточняющих вопросов получил ответы, компиляцию которых приведу в цитате.
А как с такими DSL решается задача «показать список объектов, которые я могу видеть? Надо же в SQL-запрос это как-то транслировать, не выгребать же все записи с БД.
Есть интерфейс на сайте, показывающий список чего-либо. Скажем — статей в админке CMS. Статей с базе — десятки тысяч, но обычно пользователь имеет доступ только к десятку. Как достать из БД статьи, которые видны конкретному пользователю? Ну, если мы все правила что кому видно — вынули из кода в какой-то DSL?
Другими словами — как написать запрос типа
select * from articles a
join roles r on r.userId = currentUserId
where article.owner = currentUserId
OR (r.role in ['admin', 'supevisor']) — админ всего
OR (r.domain = currentDomainId AND r.role in ['domain-admin', 'domain-supervisor']) — админ домена
У меня такие правила в коде, в виде LINQ-выражений, и я такую задачу решать умею. А возникает такая задача даже чаще, чем «проверить есть ли доступ к одному выгруженному с память объекту»
Надеюсь, я правильно понял эту конструкцию и в ходе обратного реверсинженеринга, мне удалось вытащить исходные данные для решения данной задачи. Для начала обойдемся без использования мультитенатности (домены), так как они усложняют задачу и соответственно понимание. Пример их использования я приводил в прошлой статье.
Сначала я опишу ту реализацию, которая сидит в голове у вопрошающего, чтобы вы тоже ее понимали, а затем мы эту реализацию трансформируем в решение с использованием Casbin.
Описание задачи
У нас имеется CMS, в которую пользователи через админпанель могут добавлять статьи. В адмике пользователь с ролью user может видеть только свои статьи. Статьи других людей он не может видеть, если только ему не присвоена роль admin или supervisor. Пользователь с ролью supervisor может видеть и редактировать все статьи, а admin имеет все те же права что и supervisor, но кроме этого, еще может и удалять любые статьи.
Структура, схема и содержимое БД:
Структура БД нашей CMS:
Содержимое таблицы пользователей Users
Пользователям присвоены следующие роли
Содержимое таблицы Roles
Как мы видим, Piter является администратором, а Bob — супервизором. Alice обычный пользователь, может видеть, создавать и редактировать только свои статьи.
Содержимое таблица с статьями Articles
Исходя из вопроса, выборка осуществляется для администратора (Piter, id=3) таким образом:
select * from articles a
left join roles r on r.userId = 3
where a.owner = 3
OR (r.role in ('admin', 'supevisor'))
Выборка для супервизора (Bob, id=2) таким образом:
select * from articles a
left join roles r on r.userId = 2
where a.owner = 2
OR (r.role in ('admin', 'supevisor'))
А выборка для пользователя (Alice, id=1) выглядит так:
select * from articles a
left join roles r on r.userId = 1
where a.owner = 1
OR (r.role in ('admin', 'supevisor'))
Давайте теперь попробуем использовать другой подход к авторизации, на базе библиотеки Casbin.
Подход с использованием Casbin
Для начала давайте определимся что ресурс в подходе PERM — это не столько экземпляр сущности, сколько сама сущность.
Т.е. когда мы описываем модель авторизации, под ресурсом в нашем примере подразумевается сама сущность (таблица) Статья. А не конкретная запись из этой таблицы (с Id=1 например).
Дальше необходимо уточнить, что те роли, которые используются в описании этой задачи — это не классические роли из подхода RBAC.
Роли RBAC описывают те разрешения, которые можно выполнить с сущностью. Например в классическом RBAC роль user могла бы только читать статьи, роль author могла бы наследовала роль user (т.е. чтение статей), и еще могла бы редактировать создавать новые статьи, а роль admin могла бы наследовать все предыдущие разрешения и плюс еще удалять статьи.
В описанной же нами выше задаче, по сути эти все роли не отличаются друг от друга. И user и supervisor и admin имеют одни и те же права, один набор разрешений — каждый носитель любой из ролей может создавать, редактировать или удалять статьи. Разница только в области видимости, user может видеть в админке только свои статьи, и соответственно редактировать их и удалять. А admin и supervisor не только свои, но еще и чужие.
И в этом заключается большой минус модели RBAC, так это статичная модель авторизации, и с ее помощью вообще невозможно выразить бизнес-правила, в которых используются атрибуты, значения которых заранее не известны и вычисляются в процессе работы.
Об этом подробно уже было рассказано в статье Подходы к контролю доступа: RBAC vs. ABAC
А те роли что мы используем (user, admin) — это так называемые — динамические роли. Термин не официальный, и зачастую каждый подразумеваем под ним свое, они реализуются различными способами, и описанное вопрошающим решение, которое я привел в начале статьи — один из таких подходов.
Выборка значений с учетом "динамических ролей"
Для начала давайте определим модель политики RBAC (rbac_model.conf), ее подробное описание я привел в предыдущей статье:
[request_definition]
r = sub, obj, act
[policy_definition]
p = sub, obj, act
[role_definition]
g = _, _
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.actДалее, мы убираем таблицу ролей Roles. Роли у нас теперь будут описаны в хранилище политик. Это может быть как обычный *.csv файл, так и таблица в базе данных. Для простоты я буду использовать cvs файл rbac_policy.csv:
p, user, article, read
p, user, article, modify
p, user, article, create
p, user, article, delete
g, supervisor, user
g, admin, supervisor
g, 1, user
g, 2, supervisor
g, 3, adminСуть здесь такая, что мы даем роли user права на чтение, модификацию, создание и удаление статей. Затем роль supervisor наследует права роли user. А роль admin наследует права роли supervisor.
Далее пользователю alice(1) мы присваиваем роль user, bob(2) у нас supervisor, а piter(3) — admin
В принципе этого достаточно, чтобы решить проблему, которую описывал автор вопроса.
Этот код конечно не для продакшена, а для демонстрации. Для продакшена я советую использовать cross-cutting concern с CQRS+MediatR
public IList<Article> GetArticlesForAdminPanel(int currentUserId)
{
var e = new Enforcer("CasbinConfig/rbac_model.conf", "CasbinConfig/rbac_policy.csv");
var obj = "article";
var act = "read";
//Сначала проверяем, что пользователь имеет права на чтение статей
if (e.Enforce(currentUserId.ToString(), obj, act))
{
//Получаем список ролей пользователя
var currentUserRoles = e.GetRolesForUser(currentUserId.ToString());
//Проверяем, является ли пользователем админиом или супервизором
var isAdmin = currentUserRoles.Any(x => x == "admin" || x == "supervisor");
//Если админ, вернуть все записи, иначе только те, которые принадлежат пользователю
if (isAdmin) return _context.Articles.ToList();
else return _context.Articles.Where(x => x.OwnerId == currentUserId).ToList();
}
else
{
// отклонить запрос, показать ошибку
throw new Exception("403. У вас нет прав для чтения статей");
}
}Тадам! Задача решена, ответ на вопрос дан.
Редактирование статей с учетом "динамических ролей"
Теперь же пойдем еще дальше. Мы получили список статей, отобразили в админке, и попытаемся отредактировать какую-нибудь статью. И нам соответственно надо проверить, имеем ли мы права чтобы ее отредактировать, пользователь с ролью user может отредактировать только свои статьи, supervisor и admin могут отредактировать все статьи.
Для этого определяем новую модель, называем ее rbac_with_abac_model.conf:
[request_definition]
r = sub, obj, act
[policy_definition]
p = sub, obj, act
[role_definition]
g = _, _
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = (r.sub == r.obj.OwnerId.ToString() || g(r.sub, "supervisor")) && g(r.sub, p.sub) && r.act == p.actДанная модель не сильно отличается от модели чтения, за исключением секции [matchers], в ней мы конструкцию r.obj == p.obj заменили на (r.sub == r.obj.OwnerId.ToString() || g(r.sub, "supervisor")). Это следует читать как r.sub (id пользователя) должен совпадать с полем r.obj.OwnerId (id владельца обновляемой записи) или r.sub должен входить принадлежать группе "supervisor". Поскольку группа admin наследует все права группы supervisor то и члены группы admin будут соответствовать этому правилу.
Файл с политиками остается прежним, его мы не меняем. Теперь смотрим как это выглядит в коде:
public void UpdateArticle(int currentUserId, Article newArticle)
{
var e = new Enforcer("CasbinConfig/rbac_with_abac_model.conf", "CasbinConfig/rbac_policy.csv");
var act = "modify";
//Проверяем, что пользователь имеет права на редактирование статьи
if (e.Enforce(currentUserId.ToString(), newArticle, act))
{
//Обновляем, и сохраняем изменения
_context.Articles.Update(newArticle);
_context.SaveChanges();
}
else
{
// отклонить запрос, показать ошибку
throw new Exception("403. Недостаточно прав");
}
}Здесь стоит обратить внимание на то, что мы в метод e.Enforce передаем вторым параметром объект, который представляет из себя экземпляр класса Article.
Ну и последний шаг — попытаемся удалить статью.
Удаление статьи
Бизнес-правило у нас здесь такое, что пользователь с ролью user может удалить свою статью, supervisor — не имеет прав удалять чужие статьи, а admin такое право имеет.
Опишем теперь это бизнес-правило в модели политики PERM, в файле delete_model.conf:
[request_definition]
r = sub, obj, act
[policy_definition]
p = sub, obj, act
[role_definition]
g = _, _
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = (r.sub == r.obj.OwnerId.ToString() || g(r.sub, "admin")) && g(r.sub, p.sub) && r.act == p.actОна не сильно отличается от предыдущей политике редактирования, за тем исключением, что удалять чужие статьи мы разрешили только роли admin. Если носитель роли supervisor попытается удалить чужую статью, у него выйдет ошибка превышения полномочий.
Как и в случае с моделью, код мало чем отличается от предыдущего примера на редактирование:
public void DeleteArticle(int currentUserId, Article deleteArticle)
{
var e = new Enforcer("CasbinConfig/delete_model.conf", "CasbinConfig/rbac_policy.csv");
var act = "delete";
//проверяем, что пользователь имеет права на удаление статьи
if (e.Enforce(currentUserId.ToString(), deleteArticle, act))
{
//Удаляем статью
_context.Articles.Remove(deleteArticle);
_context.SaveChanges();
}
else
{
// отклонить запрос, показать ошибку
throw new Exception("403. Недостаточно прав");
}
}Резюме
Надеюсь, данный пример продемонстрировал гибкость, универсальность и удобство использования библиотеки Casbin и языка PERM для построения решений по разделению доступа и авторизации.
Еще отмечу, что как сами модели политики, так и правила политики могут храниться в БД. И предусмотрена возможность фильтрации правил, если их большое множество, и это может стать узким местом в высоконагруженных приложениях.
Casbin под капотом использует библиотеку DynamicExpresso.Core для интерпретации простых выражений C# при сопоставлении правил политик с входными значениями, что позволяет эффективно использовать Casbin даже в самых сложных сценариях авторизации.
Не смотря на свою молодость, Casbin активно развивается, используется во множестве проектов, обрастает полезными инструментами и API. Такими например как UI для управления политиками.
Полностью работоспособный и самодостаточный код примера, который я использовал для написания данной статьи я разместил у себя на Github, можете скачать и поиграться, если есть интерес и желание.
Полезные ссылки
- Список адаптеров к хранилищам, где можно хранить правила политик
- Способы загрузки модели политики в класс Enforcer
- Интеграция Casbin c ASP.NET Core, для авторизации через атрибуты контроллеров
