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

Ссылка на высокое разрешение:http://i.stack.imgur.com/WG3Vz.png

Вот схема:

Как это устроено:

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

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

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

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

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

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

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

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