LINUX.ORG.RU

Проектирование БД для модели контроля доступа

 


0

1

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

Приведу пример:

Объекты: блогопост №1, блогопост №2, и т.д.

Роли: аноним, читатель, редактор, модератор. (Читатель, редактор и модератор должны быть привязаны к блогопосту.)

Разрешения для первого блогопоста (не фиксированные, могут быть свои для каждого объекта, плюс нужна возможность менять их):

  1. Аноним может читать блогопост №1.
  2. Читатель-бп1 может читать блогопост №1 и оставлять комментарии.
  3. Редактор-бп1 может читать и редактировать блогопост №1.
  4. Модератор-бп1 может читать, редактировать блогопост №1, а также редактировать и удалять комментарии.

Разрешения для второго блогопоста:

  • Аноним НЕ может читать блогопост №2.
  • Читатель-бп2 может читать блогопост №2.
  • Редактор-бп2 может читать и редактировать блогопост №2.
  • Модератор-бп2 может читать блогопост №2, а также удалять комментарии.

Как такую модель выразить в БД? Есть где-нибудь реализация похожей модели? Как разрешать конфликты (например, пользователь одновременно читатель и редактор блогопоста №1. Может ли он редактировать пост?)?

Пользователь ЛИБО читатель, ЛИБО редактор, в зависимости от величины приоритета над страницей - заглянул бы в любой код, тебе стало бы понятно это. Другое дело, что на этапе проектирования можно заложить функционал мимикрии под конечного юзера - как в блогодвижках кнопочка «предпросмотр».

Зачем в БП2 модератор, если комментировать нельзя?

Дл простого случая в виде бложика, который ты описал, вся задача сводится к одному полю priv в таблице user

minakov ★★★★★
()
Ответ на: комментарий от minakov

Пользователь ЛИБО читатель, ЛИБО редактор, в зависимости от величины приоритета над страницей - заглянул бы в любой код, тебе стало бы понятно это.

Разумно.

Зачем в БП2 модератор, если комментировать нельзя?

Как-то упустил это.

Дл простого случая в виде бложика, который ты описал, вся задача сводится к одному полю priv в таблице user

Разве? В приведенном примере пользователь может иметь разные роли на разные посты.

coldheadcleanhands
() автор топика

Зачем в БП2 модератор, если комментировать нельзя?

Допустим, сейчас комментарии отключены, но могут быть включены автором.

coldheadcleanhands
() автор топика
Ответ на: комментарий от coldheadcleanhands

в правильных ФС «Читатель-бп2» и «Читатель-бп1» - разные люди. Но даже если нужно разделять одного пользователя по двум блогам, то вешаешь в таблицу blog_post поле priv, чекаутя права по одному ведаемому программистам алгоритму. Хоть запретить модератором даже смотреть, а анонимам разрешить все. Если есть желание уйти в проектирование БД до такой степени, чтобы разработчики повешались - то можно насоздавать еще пару-тройку полей для каждого поста, завернуть все в nested sets, аналогично для пользователя. А еще лучше - у юзера поле вставить и туда по очереди вогнать список постов, куда ему можно. Короче, извратиться можно как угодно, но чтобы это сделать правильно - нужно либо УМЕТЬ проектировать БД, а соответственно не спрашивать, либо представить себя на месте сервера БД и разработчика, который будет мучаться запросы составлять

minakov ★★★★★
()
Ответ на: комментарий от minakov

А если сделать таблицы ROLES(role_id, role_name) и таблицу ROLE_PRIV(role_id, object_id, priv) и USER_ROLE(user_id, object_id, role_id)?

coldheadcleanhands
() автор топика

Это называется словом «ACL» (Access Control List) и реализуется каноническим образом через таблицу create table acls(id integer not nul, article_id integer not null, privilege_level integer not null, user_id integer).

Исходя из гипотезы, что «анонимный доступ всегда обладает наименьшими привилегиями», привилегии сессии расчитываются как

select max(privilege_level) from acls where article_id = :article_id and (user_id = :user /*текущий юзер */ or user_id is null /* anonymous */)

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

select max(privilege_level) from acls where article_id = :article_id and (user_id = :user /*текущий юзер */ or user_id is null /* anonymous */)

Интересно. Пожалуй, заиспользую ACL совместно с ролями. Но у меня не ACL, у меня RBAC, так что одной этой таблицей не обойдешься. Есть элементарные разрешения: читать, редактировать. Есть роли, состоящие из наборов этих разрешений. Тут простым max не получится. Надо каждое отдельное разрешение проверять.

coldheadcleanhands
() автор топика
Ответ на: комментарий от minakov

Зачем в БП2 модератор, если комментировать нельзя?

думаю, stave и leave можно прописать это в качестве картельной меры :3

stevejobs ★★★★☆
()
Ответ на: комментарий от coldheadcleanhands

Тебе всё равно делать ACL, если доступ к экземплярам одного класса различается (например, к разным статьям имеют доступ разные люди по-разному).

Здесь, на LOR'е чистый RBAC - то есть юзер либо может всё (модератор), либо только править и подтверждать новости (корректор), либо постить и править свои посты (регистрант), либо просто постить (анонимус). Если бы макском решил захотеть делать доступ к разным разделам по-разному, ему пришлось бы писать ACL, в котором указывал бы какому разделу какая привилегия у какого пользователя.

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

no-dashi ★★★★★
()

Здесь путаница насчет терминологии получилась. Роль в RBAC это роль в автоматизированной системе целиком, она не зависит от количества объектов в АС.

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

А у тебя получается, что роли как раз зависят от количества объектов-блогпостов. При добавлении блогпоста набор ролей как минимум одного пользователя меняется. Значит это не роль в смысле RBAC.

bogus_result
()

Можно же комбинировать ACL и RBAC. Например, в одной из наших АС, упрощенно: может ли пользователь запустить задачу редактирования счетов определяется ролью (роли определяют вообще все задачи с которыми он сможет работать и ограничения их внутреннего функционала), а то какие счета он сможет редактировать, определяется ACL.

bogus_result
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.