Графическое и текстовое объяснение модели управления разрешениями на основе ролей RBAC

Spring Boot

Когда мы разрабатываем систему, мы должны столкнуться с проблемой контроля разрешений, то есть разные пользователи имеют разные права доступа, операций и данных. Модели управления полномочиями, которые формируют теорию, включают: дискреционный контроль доступа (DAC: дискреционный контроль доступа), обязательный контроль доступа (MAC: обязательный контроль доступа) и контроль доступа на основе атрибутов (ABAC: контроль доступа на основе атрибутов). Модель разрешений RBAC (управление доступом на основе ролей) чаще всего используется разработчиками и относительно проста в использовании. В этой статье вы познакомитесь с этой моделью разрешений.

1. Введение в модель разрешений RBAC

Модель разрешений RBAC (управление доступом на основе ролей): управление разрешениями на основе ролей. В модели есть несколько ключевых терминов:

  • Пользователь: Оператор системного интерфейса и доступа
  • Разрешение: квалификация авторизации для доступа к интерфейсу или выполнения операции.
  • Роль: общий термин для пользователей с одинаковыми привилегиями.

Основная логика авторизации модели разрешений RBAC выглядит следующим образом:

  • Какова роль пользователя?
  • Какие права есть у роли?
  • Получите разрешения пользователя от разрешений роли

Во-вторых, процесс эволюции RBAC

2.1 Прямая связь между пользователями и разрешениями

file

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

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

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

  • Теперь пользователями являются Zhang San и Li Si. С увеличением персонала в будущем каждый пользователь должен быть повторно авторизован.
  • Или, если Чжан Сан и Ли Си уйдут, им нужно восстановить несколько разрешений для каждого пользователя.

2.2. У пользователя есть роль

В реальных групповых услугах пользователи могут быть классифицированы. Например, система управления заработной платой обычно классифицируется по уровням: менеджер, старший инженер, инженер среднего звена, младший инженер. То есть по определенным ролям пользователи с одной ролью обычно имеют одинаковые разрешения. После этого изменения можно преобразовать полномочия на основе пользователей в полномочия на основе ролей.

file

  • У пользователя есть роль
  • Роль имеет несколько разрешений на операции (меню)
  • Разрешение на операцию может принадлежать нескольким ролям

Мы можем описать такую ​​связь, используя модель проектирования базы данных на рисунке ниже.

file

2.3 Одна или несколько ролей для пользователя

Однако в практических прикладных системах один пользователь и одна роль далеко не соответствуют требованиям. Если мы хотим, чтобы пользователь временно имел и роль продавца, и роль вице-президента. Как я должен это делать? Чтобы повысить применимость дизайна системы, мы обычно разрабатываем:

  • Пользователь имеет одну или несколько ролей
  • Роль содержит несколько пользователей
  • Роль имеет несколько разрешений
  • Разрешение принадлежит нескольким ролям

Мы можем описать такую ​​связь, используя модель проектирования базы данных на рисунке ниже.

file

2. Права доступа к странице и права работы

  • Доступ к странице:Все системы состоят из страниц одна за другой, а страницы затем состоят из модулей.Могут ли пользователи видеть меню этой страницы и могут ли они войти на эту страницу, называется правами доступа к странице.
  • Разрешение на операцию:Любое действие или взаимодействие пользователя в операционной системе требует разрешений на выполнение операций, таких как добавление, удаление, изменение и проверка. Например: может ли пользователь щелкнуть кнопку, гиперссылку и должен ли пользователь видеть разрешение.

file

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

3. Разрешения на данные

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

  • Обычно права доступа к данным определяются организацией, к которой принадлежит пользователь. Например, первый производственный отдел может видеть только производственные данные своего собственного отдела, второй производственный отдел может видеть только производственные данные своего собственного отдела; отдел продаж может видеть только данные о продажах, а не данные финансового отдела. . Все данные может видеть генеральный менеджер компании.
  • В реальных бизнес-системах права доступа к данным часто бывают более сложными. Весьма вероятно, что отдел продаж может использовать данные производственного отдела для определения стратегий продаж, графиков и т. д.

Таким образом, чтобы справиться со сложными требованиями, управление разрешениями данных обычно контролируется программистами, которые пишут персонализированный SQL для ограничения объема данных, а не передают его модели разрешений, Spring Security или shiro. Конечно, эту проблему также можно решить с точки зрения модели разрешений или структуры разрешений, но их применимость ограничена.

Ждем вашего внимания

Категории