Модель базы данных наилучшего управления доступом на основе ролей (RBAC)

ruby-on-rails permissions roles access-control rbac

37438 просмотра

10 ответа

57191 Репутация автора

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

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

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

Так как же другие проектируют и реализуют свою модель RBAC?

Автор: JasonSmith Источник Размещён: 10.10.2008 05:42

Ответы (10)


2 плюса

222 Репутация автора

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

Автор: IDBD Размещён: 10.10.2008 08:49

-1 плюса

758 Репутация автора

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

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

Автор: Keith Patton Размещён: 11.10.2008 05:20

0 плюса

2543 Репутация автора

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

Автор: Yardboy Размещён: 12.10.2008 12:03

56 плюса

679 Репутация автора

Решение

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

  • Ресурсы.
  • Права доступа.
  • Пользователи.
  • Роли (т.е. группы).

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

Роли <- это наборы -> ( одного или нескольких ) разрешений .

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

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

  • разрешение
  • роль
  • пользователь
  • role_permission
  • USER_ROLE

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

Автор: Amr Mostafa Размещён: 12.10.2008 02:36

3 плюса

5481 Репутация автора

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

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

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

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

Юваль = 8-)

Автор: Yuval Размещён: 12.10.2008 05:44

-1 плюса

1517 Репутация автора

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

РЕДАКТИРОВАТЬ:

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

Автор: bluekeys Размещён: 21.12.2009 09:09

1 плюс

548 Репутация автора

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

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

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

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

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

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

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

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

Автор: detay Размещён: 12.03.2010 09:55

20 плюса

5307 Репутация автора

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

введите описание изображения здесь

Автор: Hanxue Размещён: 21.01.2014 09:50

-1 плюса

336 Репутация автора

Введение в RBAC -

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

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

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

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

2) Авторизация - определяет, что пользователь может делать и чего не может делать в приложении. Ex. «Изменение заказа» разрешено, но «создание нового заказа» не допускается.

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

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

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

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

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

Автор: Kunal Khatri Размещён: 03.08.2015 02:08

-1 плюса

1 Репутация автора

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

  1. Определить правила контроля доступа
  2. Объедините правила, чтобы построить новые правила

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

Автор: Xiao Li Размещён: 05.09.2015 06:12
Вопросы из категории :
32x32