Лучшая модель базы данных с ролевым контролем доступа (RBAC) [закрыта]

Question

Какова наилучшая схема базы данных для отслеживания ролевых элементов управления доступом для веб-приложения?

Я использую Rails, но плагин RBAC, связанный Google, выглядит не поддержанным (только 300 коммитов для SVN;последнее было почти год назад).

Концепция достаточно проста для реализации с нуля, но в то же время достаточно сложна и важна, чтобы с ней стоило разобраться.

Итак, как другие проектируют и внедряют свою модель RBAC?

Answer 1

Согласно моим довольно базовым знаниям в этой области, основными участниками RBAC являются:

• Ресурсы.
• Разрешения.
• Пользователи.
• Роли (т.е.Группы).

Ресурсы <- требовать -> (один или много) Разрешения.

Роли <- являются коллекциями -> (один или много) Разрешения.

Пользователи <- могу иметь -> (один или много) Роли.

Таблицы для такой модели были бы следующими:

• разрешение
• Роль
• пользователь
• ролевое разрешение
• пользовательская роль

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

Answer 2

Вот простая диаграмма, иллюстрирующая отличный ответ Амра Мостафы

Answer 3

Я работаю над подсистемой RBAC здесь, на работе в тот момент ... какое совпадение.

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

rule 14: guest role + page name + read permission
rule 46: approver role + add column + execute permission

и так далее. Я оставлю ERD в качестве упражнения для читателя ;-), если у вас есть вопросы, оставьте комментарий.

Yuval = 8 -)

Answer 4

Вы можете использовать плагин Restful ACL Rails .

Answer 5

Я думаю, что ответ на ваш вопрос настолько глубок, насколько вы хотите.Если вы случайно подумаете о том, чтобы распределить роли по группам, а затем связать группы с пользователями, этого будет недостаточно.В конечном итоге вам нужно будет предоставить определенные разрешения пользователю на определенный объект (форум, видео и т.д.).

Я более близок к ответу Юваля: все, что нам нужно, это связать объекты всего проекта + действия + пользователей.Чтобы обеспечить это;базовый объект (Сущность) имеет идеальный смысл.Таким образом, любой объект, наследуемый от Entity, может быть легко связан с пользователем + action.

Поскольку вы также хотите, чтобы все было просто;мое предложение было бы следующим;

• Любой объект из-за ограничений rbac должен быть производным от базового объекта.
• Должен быть список ролей, которые взаимно связаны с Сущностью.
• Должен быть список отношений между пользователями и ролями.

Чтобы продвинуться еще на один шаг, я бы также порекомендовал следующее (для автоматизированного rbac)

• Я использую доступ к своим объектам на основе сервисов.Это;Я создаю репозитории объектов (которые выполняют для меня доступ к БД) и получаю доступ к репозиториям через сервисные функции.
• Я использую пользовательский атрибут в начале каждой сервисной функции.Это определяет необходимую роль для доступа к этой функции.
• Я использую пользовательский параметр для доступа ко всем моим сервисным функциям, и каждая сервисная функция выполняет проверку роли перед выполнением самой себя.Отражение помогает мне понять, какую функцию я вызываю и какую роль она играет (через пользовательские атрибуты).
• Я также запускаю инициализатор при запуске моего приложения, и он проверяет наличие всех функций (и их атрибутов) и проверяет, добавил ли я новую требуемую роль.Если есть роль, которую я только что добавил и которой, похоже, нет в базе данных, она создает ее в базе данных.

Но, увы, это доступно только для .NET, насколько я знаю, Java не имеет пользовательских атрибутов, так что вряд ли это будет доступно для Java.

Я бы хотел привести несколько примеров кода, но мне слишком лень это делать.Тем не менее, если у вас есть вопросы о моем способе rbac;вы можете спросить здесь, и я обязательно отвечу.

Answer 6

Требование к роли очень хорошо работает с Restful Authentication, предоставляя функции аутентификации на основе ролей и в хорошем состоянии.

Answer 7

Для приложений .net вы должны посмотреть на что-то вроде Visual Guard http: //www.visual-guard. ru / , чтобы избежать необходимости обрабатывать разрешения и роли с нуля.

Кроме того, для .net у вас есть поставщики членства и ролей, а также авторизация, обработанная с помощью конфигурации. http://www.odetocode.com/Articles/427.aspx

Answer 8

Попробуйте https://github.com/ThoughtWorksStudios/piece , это механизм правил для вас управлять контролем доступа на основе ролей пользователей:

<Ол>

Определите правила контроля доступа

Объедините правила для создания новых правил

Вы можете найти полный пример приложения Rails здесь: https://github.com/xli/piece-blog

Answer 9

Введение в RBAC -

Система контроля доступа на основе ролей - это метод ограничения доступа к "некоторым источникам или приложениям или некоторым функциям приложений" на основе ролей пользователей организации.

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

И если мы немного углубимся в RBAC, то в основном он содержит 3 функции.

1) Аутентификация - подтверждает личность пользователя.Обычно это делается с помощью учетных записей пользователей и паролей или учетных данных.

2) Авторизация - она определяет, что пользователь может делать, а чего не может делать в приложении.Бывший.‘Изменение заказа’ разрешено, но "создание нового заказа’ запрещено.

3) Аудит действий пользователей над приложениями.- Он отслеживает действия пользователя в приложениях, а также кто каким пользователям предоставил доступ?

Это было очень простое изображение системы RBAC с видом сверху.

Базовая структура системы RBAC может содержать следующие компоненты:Пользователи, Роли, Разрешения или ограничения, ресурсы.

• Разрешения или ограничения – разрешения представляют собой доступ к ресурсу приложения.
• Роль – Он содержит набор разрешений
• Пользователь – пользователю назначается одна или несколько ролей, так что в конечном итоге пользователь содержит разрешения с помощью роли.

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

Answer 10

Мне очень нравится этот пост в блоге: https://content.pivotal.io/blog/access-control-permissions-in-rails

Редактировать:

Похоже, что ryanb из railscasts подумал в том же духе и создал жемчужину под названием канкан https://github.com/ryanb/cancan используя базовую технику, аналогичную публикации pivotollabs.