Як створити контроль доступу на основі ролей?

Я намагаюся керуватися рольовою моделлю контролю доступу, щоб обмежити, що користувачі можуть чи не можуть робити у моїй системі.

Поки що у мене є такі суб'єкти:

користувачі - люди, які будуть використовувати систему. Тут у мене є імена користувачів та паролі. role - Сукупність ролей, які можуть мати користувачі. Такі речі, як ресурси менеджера, адміністратора тощо - речі, якими користувачі можуть керувати. Як і контракти, користувачі, чернетки контрактів тощо. Операції, які користувачі можуть робити з ресурсами. Як створити, прочитати, оновити чи видалити.

Тепер у мене на діаграмі виникає сумнів, де я маю таке відношення:

Операції (0 .. *) виконуються на ресурсах (0 .. *), що створює таблицю, яку я називав дозволами, і яка буде зберігати операцію та ресурс .

Таблиця дозволів буде виглядати приблизно так (один її рядок): ID: 1, операція: create, resource: контракт.

Що означає дозвіл на створення в контракті .

Я зробив це таким чином, тому що я вважаю, що на деяких ресурсах можуть бути не всі види операцій. Наприклад, для реєстрації контрактів користувачі можуть завантажувати файли , але ця операція недоступна для реєстрації постачальника .

Тому зараз, коли адміністратор буде давати дозволи на роль , він не матиме списку ресурсів для кожної операції, зареєстрованої в системі.

Я думаю, що кожен ресурс має свою колекцію операцій, які можна виконати над ним.

Я можу уточнити, якщо щось не зрозуміле.

Це правильний спосіб реалізації rbac?

EDIT

Я маю на увазі те, що маючи таблицю дозволів, яка має операцію та ресурс , у мене є ДВА додаткові таблиці, тому що я хочу пов’язати ресурси з операціями . Я міг би також щойно виконаних ресурсів мати дозволи, де таблиця дозволів зберігатиме дозволи.

Але тоді б сталося, що деякі дозволи, які навіть не існують для деяких ресурсів, з'явилися б тоді, коли адміністратор призначив би їх.

Отже, я хочу знати з точки зору проектування бази даних, чи правильний цей дозвіл таблиці, який має одну колонку та інший ресурс? Чи зіткнуться я з проблемами, якщо вона залишиться такою?

Ваш дизайн мені здається досить близьким. Всього пара пропозицій.

користувачі - люди, які будуть використовувати систему. Тут у мене є імена користувачів та паролі.

Чудово

role - Сукупність ролей, які можуть мати користувачі. Такі речі, як менеджер, адміністратор тощо.

Теж добре. Але вам також знадобиться сутність / таблиця "UserRoles", яка підкаже, які користувачі виконують які ролі. Цілком імовірно, що певний користувач може мати дві або більше ролей.

ресурси - речі, якими користувачі можуть керувати. Як і контракти, користувачі, проекти контрактів тощо.

Це може бути лише питання семантики. Я не думаю, що користувачі безпосередньо маніпулюють ресурсами; ролі роблять. Таким чином, це переходить на користувача -> роль користувача -> роль -> операція -> ресурс

операції - речі, які користувачі можуть робити з ресурсами. Як створити, прочитати, оновити чи видалити.

так, крім "ролей" замість "користувачів"

Таблиця дозволів буде виглядати приблизно так (один її рядок): ID: 1, операція: create, resource: контракт. Що означає дозвіл на створення договору.

Хммм. Є два шляхи для цього. Ви можете мати таблицю дозволів, яку ви описуєте, але вам також знадобиться додаткова RolePermissionsтаблиця / сутність, яка повідомляє, яка роль має який дозвіл. Але я не впевнений, що це необхідно.

Найпростіший спосіб зробити це таблиця / сутність дозволів із цими стовпцями / атрибутами: Ідентифікатор ролі, Ідентифікатор операції, ResourceID. Таким чином, операції x комбінації ресурсів присвоюються безпосередньо ролі, а не завантажуються в дозвіл, призначений ролі. Це усуває одну сутність. Справді немає необхідності в окремій таблиці дозволів рольових агностів, якщо ви не хочете заздалегідь визначити, які комбінації дозволів дозволені, а які - ні.

Я б не використовував і не реалізував RBAC. Натомість я б використав ABAC. Дозволь пояснити...

• RBAC або управління доступом на основі ролей - це управління користувачем та призначення ролі. У RBAC ви можете сказати, що Аліса - менеджер. Ви можете визначити статичні дозволи разом з цим. Наприклад, менеджер може затвердити позики. Тож існує посилання від Аліси до менеджера, щоб затвердити Позику як дозвіл. Існує безліч систем, які дозволять вам це робити, тому вам не потрібно реалізовувати власні таблиці. Навіть LDAP має підтримку обмежених наборів RBAC. Це нормально, якщо у вас є відносно невеликий набір ролей і дозволів. Але що робити, якщо ви хочете врахувати конкретні дозволи, як це має бути? Переглянути, видалити, вставити? Що робити, якщо ви хочете взяти до уваги відносини?
• Контроль доступу ABAC або на основі атрибутів стосується чіткої авторизації, орієнтованої на політику. За допомогою ABAC ви можете використовувати ролі, визначені в RBAC, і писати політики, наприклад
  • Менеджери можуть переглядати документи у своєму відділі
  • Співробітники можуть редагувати документи, якими вони володіють

У своєму питанні ви по суті визначили інформаційну модель. Ваші об'єкти та їх атрибути, наприклад, користувач (ім'я, пароль, відділ ...); об'єкт (наприклад, договір) тощо.

Таким чином, в ABAC ви повністю від'єднаєте код / ​​логіку програми від логіки авторизації, яка потім зберігається як поліси з використанням атрибутів. Самі дозволи зберігаються прямо в політиці (див. Приклад вище). Архітектура розгортання ABAC виглядає наступним чином

Справа в тому, що якщо ви використовуєте підхід ABAC, ви пишете політику для ABAC (або в XACML, або в ALFA - для цього є безліч інструментів), і вам більше ніколи не доведеться повторно налаштовувати код або користувацьку реалізацію RBAC або контроль доступу.