Реализация MySql для управления доступом на основе ролей

Я собираюсь разработать веб-приложение для управления с помощью Laravel.

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

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

Поэтому я решил использовать подход RBAC, чтобы получить определенную гибкость. Я буду использовать эту схему БД (просто пример схемы, но представляющий потребности моего приложения):

пример базы данных

Мой ответ таков: поскольку существует прямая связь между пользователями и бумагой, клиентом, вложениями и т. д., как выражаются правила RBAC? Я должен проверять разрешение пользователя во внешнем интерфейсе, когда он запрашивает операцию или ресурс? Или есть способы выразить эти правила даже на бэкэнд-уровне? Может быть, используя некоторые варианты GRANT?

Надеюсь, sby может помочь. Благодарю вас!


mysql database laravel role-based-access-control rbac
person Federico Arona    schedule 02.11.2019    source источник
comment
Вы должны проверить, хотите ли вы добавить пользователей в свою базу данных и достаточны ли привилегии, которые вы можете предоставить каждому пользователю. Но я считаю, что вы должны сделать этот клиентский сайт   -  person nbk    schedule 02.11.2019
comment
Ну, это долгий путь, чтобы сохранить все это на стороне MySQL ... с таблицей разрешений, функцией, которая проверяет эту таблицу разрешений, и просмотром с опцией проверки, она также может работать вне курса.. -› mariadb.com/resources/blog/ .. .   -  person Raymond Nijland    schedule 02.11.2019
comment
@RaymondNijland Я думаю, что безопасность на уровне строк - это не то, что мне нужно. Приведем пример: - У меня три группы: админ, помощники и рабочие - Один админ может добавить нового клиента и написать на бумаге все, что хочет. - Один помощник может написать только бумажную часть 1. - Один рабочий может написать только бумажную часть 2. В любом случае любой администратор и любой помощник могут видеть все на бумаге, а рабочие могут видеть только бумажную часть 2 любой бумаги. Но увидеть бумажную часть 2 может любой рабочий, а не только рабочий, который ее написал. Таким образом, политики применяются к таблице, а не к отдельной строке.   -  person Federico Arona    schedule 02.11.2019
comment
Я думаю, что безопасность на уровне строк — это не то, что мне нужно. Да, достаточно честно, вы проверили последнюю ссылку, которая больше похожа на систему управления доступом на основе ролей с битовыми масками. В любом случае вы можете использовать это метод как более подходящую систему на основе ролей (больше записей для ваших групп вместо масок), если вы измените код SQL...   -  person Raymond Nijland    schedule 02.11.2019
comment
... Но здесь все угадывается, что вам может понадобиться. См. как спросить и см. Почему я должен предоставлять Минимальный воспроизводимый пример для очень простого SQL-запроса? у нас есть лучшее понимание данных и вашего пользовательского варианта. Но, как уже сказал @nbk, это, скорее всего, лучше и проще обрабатывается приложением.   -  person Raymond Nijland    schedule 02.11.2019
comment
Ну да, последняя ссылка кажется очень близкой к тому, что мне нужно. Я попробую.   -  person Federico Arona    schedule 02.11.2019
comment
Хорошо, я дам более подробную информацию, если обнаружу, что последнее решение мне не подходит. Мне очень жаль, что мой вопрос неясен, это мой первый подход к разработке веб-приложений за пределами университета, поэтому я немного в начале   -  person Federico Arona    schedule 02.11.2019
comment
Ну да, последняя ссылка очень близка к тому, что мне нужно. Я попробую. Возможно, вам нужна комбинация и использование системы управления доступом на основе ролей с битовой маской. Как вы сказали, один администратор, помощник и рабочий, который также предлагает битовую маску поверх нее и вы использовали любой более поздний вариант, который предлагает управление доступом на основе ролей на основе групп. Но это может быть неправильной интерпретацией вашего примера, поскольку это, скорее всего, означает блокировку записи, поэтому другой, у которого также есть разрешения на запись, не может модифицировать запись до того, как другой будет завершен. .   -  person Raymond Nijland    schedule 02.11.2019
comment
вы можете использовать ACL для разрешения роли   -  person Vikas Katariya    schedule 02.11.2019

Ответы (1)


arrow_upward
2
arrow_downward

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

Вы определяете роли, такие как User и Customer, разрешения, такие как can-write-paper, can-read-paper, и назначаете их ролям или отдельным пользователям в зависимости от вашего варианта использования.

person Peppermintology    schedule 02.11.2019
comment
Это кажется очень полезным. Я попробую и дам вам знать! Спасибо - person Federico Arona; 02.11.2019
comment
Я отмечаю это как правильный ответ, поскольку Laratrust был именно тем, что мне было нужно для моей области. В любом случае я, вероятно, добавлю RoleLevel в каждую таблицу, чтобы управлять вставкой, удалением и т. д. даже на бэкэнде. - person Federico Arona; 08.11.2019
comment
@FedericoArona - Рад, что это работает для вас. Что вы имеете в виду под RoleLevel управлением операциями insert и delete? Это звучит как permission для меня. - person Peppermintology; 08.11.2019
comment
Вы также можете использовать Casbin для RBAC: github.com/php-casbin/laravel-authz - person Yang Luo; 13.03.2021