DB Схема управления доступом на основе ролей

Question

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

Ссылка на выс: http://i.stack.imgur.com/WG3Vz.png

Heres схема:

Как это работает:

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

Ассоциация структурирована в подразделениях, подразделениях и т. д. (таблица intern_structures). Каждый клиент может быть членом в нескольких подразделениях, подразделениях, секциях и т. Д.

Каждый клиент может иметь одну или несколько ролей в таких членствах (подразделениях, ...), таких как президент, актуарий, казначей и т. Д., И каждая роль имеет определенные привилегии, которые владелец роли может применить к другим в своем подразделении, подразделении, секции и т. д.

Учетные данные связаны с определенным действием приложения. Владелец учетных данных может выполнить это действие на других членах в своем объеме. Могут быть несколько «автономных» приложений, но все они имеют одну и ту же систему авторизации/авторизации.

Приложение структурировано в модулях/субмодулях/действиях и т. Д. Примером может быть модуль «Личные данные», и этот модуль содержит подмодуль под названием «Изображение», и вы можете применять действия «просмотр, удаление, редактирование» на эта картинка. Но вы не можете удалить любую картинку, если человек, чья фотография, которую вы пытаетесь удалить, находится в подразделении/разделе, где у вас есть достаточная роль.

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

Исключением является то, что вы можете дать кому-то определенные учетные данные напрямую (client_credentials). Это необходимо, если кому-то нужно выполнить определенные действия на тех, кто не находится в разделе divsion/section.

Итак, кто-то может быть членом нескольких разделов/разделов и получать несколько ролей в каждом подразделении/разделе, членом которого он является. Я собираюсь объединить все учетные данные, которые кто-то имеет через его несколько ролей. И учетные данные всегда положительные, означает, что ограничительные учетные данные невозможны.

Answer 1

Я собираюсь привести еще один пример системы RBAC, мне очень нравится. пожалуйста, проверьте рамки radicore Тони Марстон here.

Я не уверен, что он соответствует всем вашим требованиям, но что-то, что вы можете сравнить, может помочь.

Answer 2

я, кажется, не будет видеть большую часть RBAC отображений, таких как:

Operation = Any action, such as CRUD operations 
Object  = Reference to any object instance 

Permission = Mapping of 'Operation' + 'Object' 

Я не уверен, что все ваши «учетных» таблицы? Обычно учетные данные содержат свойства для подтверждения своей личности (то есть: имя пользователя/пароль). Почему у вас есть учетные данные для ролей?