Модель базы данных Best Role-Based Access Control (RBAC) [закрыто]

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

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

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

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

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

Юваль =8-)

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

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

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

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

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

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

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

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

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

Требование К Роли работает с RESTful проверки подлинности очень хорошо представить ролевое авт функций и ухоженные.

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

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

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

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

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

Мне очень нравится этот пост в блоге, http://pivotallabs.com/users/nick/blog/articles/272-access-control-permissions-in-rails.

EDIT:

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

введение в RBAC -

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

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

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

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

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

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

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

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

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

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