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

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

Пока у меня есть следующие объекты:

пользователи - люди, которые будут использовать систему. Здесь у меня есть имена пользователей и пароли. Роли - Коллекция ролей, которые могут иметь пользователи. Вещи, такие как ресурсы менеджера, администратора и т. Д. - вещи, которыми пользователи могут манипулировать. Подобно контрактам, пользователям, черновикам контрактов и т. П. Операциям - то, что пользователи могут делать с ресурсами. Как создать, прочитать, обновить или удалить.

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

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

Таблица разрешений будет выглядеть следующим образом (одна строка): ID: 1, операция: создание, ресурс: контракт.

Что означает разрешение на создание в контракте .

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

Так что теперь, когда администратор будет давать разрешения на роль , у него не будет списка ресурсов для каждой отдельной операции, зарегистрированной в системе.

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

Я могу уточнить, если что-то не понятно.

Это правильный способ реализации rbac?

РЕДАКТИРОВАТЬ

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

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

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

Ваш дизайн кажется мне очень близким. Просто пара предложений.

пользователи - люди, которые будут использовать систему. Здесь у меня есть имена пользователей и пароли.

хорошо

Роли - Коллекция ролей, которые могут иметь пользователи. Вещи, как менеджер, администратор и т. Д.

Тоже хорошо. Но вам также понадобится сущность / таблица UserRoles, которая скажет вам, у каких пользователей какие роли. Вполне вероятно, что данный пользователь может иметь две или более роли.

ресурсы - вещи, которыми пользователи могут манипулировать. Как контракты, пользователи, проекты контрактов и т. Д.

Может быть, это просто вопрос семантики. Я не думаю, что пользователи напрямую манипулируют ресурсами; роли делают. Таким образом, идет пользователь -> роль пользователя -> роль -> операция -> ресурс

операции - то, что пользователи могут делать с ресурсами. Как создать, прочитать, обновить или удалить.

да, кроме "ролей" вместо "пользователей"

Таблица разрешений будет выглядеть следующим образом (одна строка): ID: 1, операция: создание, ресурс: контракт. Что означает разрешение на создание контракта.

Хммм. Есть два способа пойти с этим. Вы можете иметь таблицу разрешений, которую вы описываете, но вам также понадобится дополнительная RolePermissionsтаблица / сущность, которая сообщает вам, какая роль имеет какое разрешение. Но я не уверен, что это необходимо.

Более простой способ сделать это - таблица / объект разрешений со следующими столбцами / атрибутами: идентификатор роли, идентификатор операции, идентификатор ресурса. Таким образом, комбинации операций x ресурсов назначаются непосредственно роли, а не загружаются в разрешение, назначенное роли. Это устраняет одну сущность. В действительности нет необходимости в отдельной таблице разрешений, не зависящей от роли, если только вы не хотите заранее определить, какие комбинации разрешений разрешены, а какие нет.

Я бы не стал использовать или внедрять RBAC. Вместо этого я бы использовал ABAC. Позволь мне объяснить...

• RBAC или управление доступом на основе ролей - это управление пользователями и назначение ролей. В RBAC вы можете сказать, что Алиса - менеджер. Вы можете определить статические разрешения вместе с этим. Например, менеджер может утверждать кредиты. Так что есть ссылка от Алисы на менеджера, чтобы утвердить кредит в качестве разрешения. Существует множество систем, которые позволят вам сделать это, поэтому вам не нужно реализовывать свои собственные таблицы. Даже LDAP поддерживает ограниченные наборы RBAC. Это нормально, если у вас относительно небольшой набор ролей и разрешений. Но что, если вы хотите принять во внимание конкретные разрешения, как в вашем случае? Посмотреть, удалить, вставить? Что если вы хотите принять во внимание отношения?
• ABAC или управление доступом на основе атрибутов - это детализированная авторизация на основе политик. С ABAC вы можете использовать роли, определенные в RBAC, и писать политики, например:
  • Менеджеры могут просматривать документы в своем отделе
  • Сотрудники могут редактировать свои документы

В своем вопросе вы по сути определили информационную модель. Ваши объекты и их атрибуты, например, пользователь (имя, пароль, отдел ...); объект (например, контракт) и так далее.

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

Дело в том, что если вы используете подход ABAC, вы пишете политики для ABAC (либо в XACML, либо в ALFA - для этого есть множество инструментов), и вам больше никогда не придется заново настраивать или настраивать RBAC или контроль доступа.