Какова наилучшая схема базы данных для отслеживания управления доступом на основе ролей для веб-приложения?
Я использую Rails, но подключаемый модуль RBAC, связанный с Google, выглядит неподдерживаемым (всего 300 коммитов в SVN; последний был почти год назад).
Концепция достаточно проста, чтобы ее можно было реализовать с нуля, но в то же время достаточно сложна и важна, чтобы ее можно было реализовать правильно.
Так как же другие проектируют и реализуют свою модель RBAC?
Насколько я знаю в этой области, основными действующими лицами RBAC являются:
Ресурсы ‹- требуют -> (один или несколько) Разрешения.
Роли ‹ – это наборы -> (одного или нескольких) разрешений.
Пользователи ‹- могут иметь -> (одну или несколько) ролей.
Таблицы для такой модели будут:
Теперь вы можете также включить сюда ресурсы, если хотите, чтобы пользователи вашего приложения могли настраивать разрешения, необходимые для ресурса. Но мне это никогда не было нужно. Надеюсь, это поможет.
Вот простая диаграмма, иллюстрирующая отличный ответ Амра Мостафы
User one-to-many User_Role many-to-one Role one-to-many Role_Permission many-to-one Permission. и сущность Resource опущена.
- person Arash; 01.03.2021
Я работаю над подсистемой RBAC здесь, на работе, в этот момент... какое совпадение.
Моя модель основана на строительных блоках различных сущностей в системе, которым требуются разрешения, будь то атрибуты для просмотра/обновления или действия для выполнения. Конечно, в системе также есть разные роли (которые можно назначать пользователям), а связующим звеном, скрепляющим все это, является правило доступа, которое связывает определенную роль, определенный объект, которому требуется разрешение, и предоставленное разрешение. Правило доступа может выглядеть следующим образом:
rule 14: guest role + page name + read permission
rule 46: approver role + add column + execute permission
и так далее. Я оставлю ERD читателю в качестве упражнения ;-) если у вас есть вопросы, оставьте комментарий.
Юваль =8-)
Вы можете использовать плагин Restful ACL Rails.
Я думаю, что ответ на ваш вопрос идет так глубоко, как вы хотите. Если вам случится подумать о том, чтобы поместить роли в группы, а затем связать группы с пользователями, этого будет недостаточно. В конце концов вам нужно будет дать определенные разрешения пользователю на определенный объект (форум, видео и т. д.).
Я ближе к ответу Юваля, все, что нам нужно, это связать объекты всего проекта + действия + пользователей. Чтобы обеспечить это; базовый объект (сущность) имеет смысл. Таким образом, любой объект, наследуемый от Entity, может быть легко связан с пользователем + действием.
Поскольку вы также хотите, чтобы все было просто; мое предложение было бы;
Чтобы сделать еще один шаг вперед, я бы также рекомендовал следующее (для автоматизированного rbac):
Но, увы, это доступно только для .NET, насколько я знаю, у Java нет настраиваемых атрибутов, поэтому вряд ли это будет доступно для Java.
Я хотел бы придумать несколько примеров кода, но мне лень это делать. Тем не менее, если у вас есть вопросы о моем способе rbac; Вы можете спросить здесь, и я обязательно отвечу.
Role Requirement очень хорошо работает с Restful Authentication, предоставляя функции аутентификации на основе ролей. поддерживается.
Попробуйте https://github.com/ThoughtWorksStudios/piece, это механизм правил для управления пользователями. управление доступом на основе ролей:
Вы можете найти полный пример приложения Rails здесь: https://github.com/xli/piece-blog
Для приложений .net вам следует взглянуть на что-то вроде Visual Guard http://www.visual-guard.com/ чтобы избежать необходимости обрабатывать разрешения и роли с нуля.
Также для .net у вас есть поставщики членства и ролей, а авторизация обрабатывается конфигурацией. http://www.odetocode.com/Articles/427.aspx
Введение в RBAC —
Система управления доступом на основе ролей — это метод ограничения доступа к «некоторым источникам или приложениям или некоторым функциям приложений» на основе ролей пользователей организации.
Здесь ограничения могут быть с помощью нескольких разрешений, которые создаются администратором для ограничения доступа, и эти разрешения в совокупности представляют собой роль, которая будет назначена пользователю.
И если мы немного углубимся в RBAC, он в основном содержит 3 функции.
1) Аутентификация — подтверждает личность пользователя. Обычно это делается с помощью учетных записей пользователей и паролей или учетных данных.
2) Авторизация — определяет, что пользователь может делать и что не может делать в приложении. Бывший. «Изменение заказа» разрешено, но «создание нового заказа» не разрешено.
3) Аудит действий пользователя в приложениях. - Он отслеживает действия пользователя в приложениях, а также то, кто каким пользователям предоставил какой доступ?
Это был очень простой вид системы RBAC сверху.
Базовая структура системы RBAC может содержать следующие компоненты: пользователи, роли, разрешения или ограничения, ресурсы.
В дополнение к этому вы также можете иметь набор пользователей, называемых группами, и роли могут быть назначены группам, если вы хотите поддерживать сложные сценарии. Итак, это была очень основная информация о структуре RBAC.
Мне очень нравится этот пост в блоге: https://content.pivotal.io/blog/access-control-permissions-in-rails
РЕДАКТИРОВАТЬ:
Похоже, что ryanb из railscasts думал в том же направлении и создал гем под названием cancan https://github.com/ryanb/cancan, используя базовую технику, похожую на сообщение pivotollabs.
