предисловие

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

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

1. Модель разрешений

На сегодняшний день самой популярной моделью разработки разрешений является модель RBAC, управление доступом на основе ролей.

1.1 Модель RBAC0

Модель RBAC0 выглядит следующим образом:

Это самые основные права - это ядро модели, которая включает в себя пользователя / роли / разрешения, которые пользователи и роли - это многие отношения, роли и разрешения, отношения составляют много для многих.

ПользовательЭто основной орган, который инициирует операцию.В зависимости от типа его можно разделить на пользователей 2B и 2C.Они могут быть пользователями фоновой системы управления, внутренними сотрудниками системы OA или пользователями, обращенными к стороне C, например как пользователи Alibaba Cloud.

РольОн действует как мост и соединяет отношения между пользователями и разрешениями.Каждая роль может быть связана с несколькими разрешениями.В то же время пользователь связан с несколькими ролями, поэтому у пользователя есть несколько разрешений для нескольких ролей.

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

Однако в реальной корпоративной системе база пользователей относительно велика, и многие из них имеют одинаковые полномочия, что является просто общими полномочиями доступа.Если администратор авторизует 100 или более человек, рабочая нагрузка огромна.

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

разрешение:

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

Разрешения страницы:

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

Разрешение на операцию:

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

Некоторым системам требуется «видимость для работы», что означает, что если кнопка операции видна на странице, то пользователь может работать.Для выполнения этого требования здесь необходим внешний интерфейс.Разработка внешнего интерфейса кэширует разрешение пользователя информацию и сохраняет ее на странице. Определяет, есть ли у пользователя это разрешение, если да, то отображает кнопку, если нет, то скрывает кнопку.

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

разрешение на данные:

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

У некоторых крупных компаний есть много городов и филиалов по всей стране.Например, пользователи в Ханчжоу могут видеть данные только по Ханчжоу при входе в систему, а пользователи в Шанхае могут видеть только данные по Шанхаю.Решение обычно заключается в том, чтобы связать данные с конкретной организационной структурой.

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

Выше приведена основная конструкция и анализ модели RBAC.Эта модель также называется RBAC0.Основываясь на основных концепциях, RBAC также предоставляет расширенную модель. Включая модели RBAC1, RBAC2, RBAC3. Три типа описаны ниже.

1.2 Модель RBAC1

Эта модель вводит понятие наследования ролей (Hierarchical Role), то есть роли имеют отношения между верхним и нижним уровнями, а отношения наследования между ролями можно разделить на отношения общего наследования и отношения ограниченного наследования.

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

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

1.3 Модель RBAC2

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

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

Разделение ответственности включает статическое разделение ответственности и динамическое разделение ответственности. В основном включают следующие ограничения:

взаимоисключающие роли:

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

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

Сервисное ограничение:

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

Предварительные роли:

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

1.4 Модель RBAC3

То есть самое полное управление полномочиями, оно основано на RBAC0, который интегрирует RBAC1 и RBAC2.

1.5 Группы пользователей

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

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

В зависимости от того, имеет ли группа пользователей отношение «верхний-нижний», ее можно разделить на группы пользователей «верхний-нижний» и обычные группы пользователей:

Группа пользователей с высшими и низшими отношениями:

Самый типичный пример — это отделы и должности.Большинство людей могут не связывать должности отделов с группами пользователей.

Конечно, группы пользователей могут быть расширены.Отделы и должности часто используются во внутренних системах управления, если это система, ориентированная на C-сторону. Подпишитесь на официальный аккаунт Java Journey Ответить Руководство Получить Java Interview Daquan

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

Общая пользовательская группа:

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

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

Организации и должности задействованы в каждой компании, и мы сосредоточимся на этих двух ниже.

1.5.1 Организация

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

Мы можем организовать и ассоциировать роли, пользователи присоединяются к организации, она автоматически получит полную роль Организации, без необходимости вручную предоставить администратора, значительно снижая рабочую нагрузку, в то время как пользователи в трансфере Cong просто отрегулируйте Организацию, роль на пакет Отказ

Еще одна роль организации – контроль разрешений на данные. При связывании роли с организацией роль может видеть только разрешения на данные в организации.

1.5.2 Работа

Предположим, что позиция финансового отдела такова:

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

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

1.6 Модели с организациями/должностями/группами пользователей

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

В зависимости от сложности системы отношения «многие ко многим» и «один к одному» могут различаться.

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

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

2. В случае распределенной системы и одного типа пользователя, система разрешений здесь сильно усложнится, и здесь будет введено понятие «система».

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

4. В случае распределенной системы с несколькими типами пользователей, такой как Taobao.com, ее типы пользователей включают внутренних пользователей, продавцов и обычных пользователей.Внутренние пользователи входят в несколько фоновых систем управления, а продавцы — в продавца. центр.Они используются для управления полномочиями.Если вы архитектор, как вы должны проектировать?Бог может оставить сообщение в области комментариев, чтобы общаться!

2. Процесс авторизации

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

Ручная авторизация:

Администратор входит в центр авторизации для авторизации пользователей.Существует два способа авторизации в зависимости от того, на какой странице: добавление ролей пользователям и добавление пользователей в роли.

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

Разрешение о разрешении:

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

3. Структура таблицы

С помощью приведенной выше модели разрешений несложно спроектировать структуру таблицы.Ниже представлена структура таблицы в нескольких системах.При простом дизайне она в основном дает идеи:

4. Структура разрешений

Apache Shrio
Spring Security

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

5. Заключение

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

прочитать три вещи

Если вы считаете, что этот контент очень полезен для вас, я хотел бы пригласить вас сделать мне три небольших одолжения:

Лайки, репосты и ваши "лайки и комментарии" - движущая сила моего творчества.

Обратите внимание на паблик «Java Fighting Emperor» и время от времени делитесь оригинальными знаниями.

В то же время вы можете рассчитывать на последующие статьи🚀

Архитектор Али сказал: система разрешений должна быть разработана так