Схема БД контроля доступа на основе ролей

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

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

Вот схема: Схема БД

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

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

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

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

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

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

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

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

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


credentials mysql rbac db-schema
person sled    schedule 10.09.2010    source источник
comment
Вот концепция простой системы RBAC: stackoverflow.com/questions/28157798/   -  person sled    schedule 05.02.2015
comment
я думаю это слишком сложно для новичков   -  person Martian2049    schedule 29.06.2018

Ответы (2)


arrow_upward
6
arrow_downward

Я собираюсь привести еще один пример системы RBAC, которая мне очень нравится. ознакомьтесь с рамкой Radicore от Тони Марстона здесь .

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

person AnaZgombic    schedule 29.03.2011
comment
Я не думаю, что этот ресурс полезен, потому что он использует свою собственную терминологию и не ссылается на стандарт (например, NIST). - person Anthony O; 19.01.2021

arrow_upward
0
arrow_downward

Кажется, я не вижу многих сопоставлений RBAC, таких как:

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

Permission = Mapping of 'Operation' + 'Object'

Я не уверен, что это за все ваши "учетные" таблицы? Учетные данные обычно содержат свойства, подтверждающие личность (например, имя пользователя / пароль). Почему у вас есть учетные данные для ролей?

person Jeach    schedule 09.02.2014