Система управления правами RBAC: все от бизнес-потока до потока данных и отображения прототипа

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

1. Бизнес-процесс

ERP-система, планирование ресурсов предприятия, планирование ресурсов предприятия. Как следует из названия, прежде всего, каковы ресурсы предприятия? Мы видели Kingdee, UFIDA, SAP и другие ERP-системы, когда система развернута, консультант по внедрению всегда сначала упоминает одно слово: фоновая система управления. Система управления фоном также предназначена для пользователей, и система управления фоном должна быть неотделима от слова, называемого авторитетом. Управление правами в основном предназначено для предотвращения проблемы утечки данных, вызванной отсутствием контроля прав. Итак, задача, которую нам нужно решить:

Какой пользователь в каком отделе имеет какие разрешения?

Чтобы решить эту проблему, мы должны упомянуть модель: модель управления разрешениями RBAC (Role-Based Access Control)
. Поэтому нам нужно сосредоточиться на трех ключевых словах: пользователь, роль и разрешение.

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

1. Таблица отделов, компания может иметь несколько отделов;
2. Таблица пользователей, пользователь может принадлежать к нескольким отделам;
3. Таблица ролей: система имеет несколько ролей, которые обычно делятся на системного администратора, администратора и обычного пользователя;
4. таблица ролей пользователей, таблица ролей пользователей, то есть пользователь может иметь несколько ролей, сохраняя отношения сопоставления между пользователями и ролями;
5. Таблица разрешений, разрешения делятся на разрешения страницы, разрешения данных и разрешения операций;
6. Таблица разрешений ролей; какие разрешения на страницы, разрешения на данные и разрешения на операции могут быть у каждой роли.

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

2. Поток данных

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

Каждому менеджеру по продукту B-end рекомендуется изучить инструменты моделирования UML, которые очень полезны для бизнес-анализа на работе.

Каждая таблица очень похожа, в основном id и name. В частности, таблица sys_role_user, uid и rid соответственно связаны с таблицей sys_user и таблицей sys_role путем установления внешних ключей. Точно так же таблица разрешений роли sys_role_permission также устанавливается через внешние ключи.

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

3. Функциональный прототип

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

1. Организационное управление
   Организационное управление в основном заключается в построении организационной структуры компании, продуктов B-end, особенно крупных систем ERP и т. Д., Прежде всего, необходимо решить организационную структуру компании. Он включает в себя нижний слой, который представляет собой таблицу отделов, о которой мы упоминали ранее. (системный_отдел)
2. Управление персоналом
   Организационное управление Для установления иерархической связи между отделами необходимо ввести информацию о сотрудниках. Он включает в себя нижний слой, который представляет собой таблицу персонала, о которой мы упоминали ранее. (системный_пользователь)
3. Управление правами
   Управление правами в основном делится на три категории: авторизация администратора организации, авторизация роли и прямая авторизация пользователя.
   (1) Для крупных компаний авторизация администратора организации, то есть авторизация руководителя отдела;
   (2) авторизация роли, то есть роли, связанные с пользователем, и унифицированная авторизация для определенной роли; (sys_role_user);
   (3) прямая авторизация пользователя , для масштаба компании меньше, пользователи могут быть авторизованы напрямую.

Разрешения в основном делятся на:
разрешения функций, разрешения полей и правила данных. То есть разрешения страницы, разрешения данных и разрешения операций, о которых мы упоминали ранее.

4. Лицензия управляет
   системой B-end, и ее использование ограничено. Общие компании будут продавать лицензии. С точки зрения непрофессионала, сколько разрешений может войти в систему.
   Назначение прав и назначение разрешений обязательны.
   Распределение разрешений: пользователи могут входить в систему со своей учетной записью и паролем;
   распределение полномочий: после входа в систему, какие функции можно использовать, зависит от полномочий, назначенных пользователю системой управления полномочиями.

Страница входа

Главная

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

В этом сообщении в блоге кратко анализируется, как модель управления разрешениями RBAC реализуется в реальном бизнесе. Любые идеи приветствуются для обсуждения.