Плавные настраиваемые разрешения

Java

Flowable по умолчанию предоставляет набор собственного интерфейса управления разрешениями (IDM), но начиная с Flowable 6 компоненты IDM стали независимыми и разделены на несколько разных модулей: flowable-idm-api, flowable-idm-engine, flowable-idm. -spring и flowable-idm-engine-configurator.

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

Реализация по умолчанию

Flowable по умолчанию предоставляет два способа работы с разрешениями:

1 Через IdentityService эта служба в основном используется для управления пользователями и группами и не может управлять определенными разрешениями. это простая версия

processEngine.getIdentityService();

2 С помощью IdmIdentityService можно обрабатывать пользователей и группы, а также одновременно обрабатывать определенные разрешения (Privilege), что улучшено в IdentityService, но это два разных интерфейса.

IdmEngineConfigurator idmEngineConfigurator = new IdmEngineConfigurator();
cfg.setIdmEngineConfigurator(idmEngineConfigurator);
// 会初始化processEngine，同时初始化配置在里面的Configurator，如IdmEngineConfigurator
ProcessEngine processEngine = cfg.buildProcessEngine();
IdmIdentityService idmIdentityService = idmEngineConfigurator.getIdmEngineConfiguration().getIdmIdentityService();

Оба сервиса используют одну и ту же таблицу в Flowable:

  • Пользователь, сохраненный в ACT_ID_USER, будет сохранен в нем при вызове интерфейса saveUser.
  • ACT_ID_INFO хранит информацию об атрибуте пользователя, ключ устанавливается при установке интерфейса setUserInfo, и в нем хранится информация о значении
  • ACT_ID_GROUP хранит информацию о вновь созданной группе Flowable, в ней будет храниться saveGroup.
  • ACT_ID_MEMBERSHIP В нем будут существовать отношения между пользователями и группами, пользователи и группы могут быть многие ко многим
  • Разрешения Хранилище ACT_ID_PRIV можно использовать, createPrivilege добавит запись
  • ACT_ID_PRIV_MAPPING сохраняет отношение сопоставления между идентификатором пользователя или идентификатором группы и разрешениями, addGroupPrivilegeMapping или addUserPrivilegeMapping добавит новую запись
  • ACT_ID_TOKEN Токен, связанный с пользователем, saveToken сохранит новую запись

**Примечания:** Видно, что IDM, официально предоставленный Flowable, также может в определенной степени выполнять операции RBAC (управление доступом на основе ролей), но когда управление правами немного сложнее, IDM не может удовлетворить наши операции. .

user -> user

group -> role

PRIV -> access control

Пользовательское управление правами

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

  • Вариант 1. Синхронизируйте информацию собственной таблицы разрешений, адаптируйтесь к структуре таблицы Flowable и по-прежнему используйте сервисный интерфейс, предоставляемый IDM, для работы.
    • Плюсы: не навязчиво для Flowable, нет необходимости вводить дополнительный контент.
    • Недостаток: когда уже есть система управления правами, при наличии двух несоответствий данных будет добавлено дополнительное обслуживание данных.
  • Вариант 2. Напишите собственный код, реализуйте интерфейс IdmIdentityService и обработайте собственную логику управления разрешениями. Официальный предоставляет решение интеграции LDAP, которое можно использовать напрямую, Мы не обязательно используем LDAP, но реализация кода в нем относительно классическая, вы можете обратиться к нему.
    • Преимущества: пользовательская реализация, гибкая, независимо от того, какую систему разрешений можно написать и адаптировать
    • Недостаток: если другие группы хотят получить доступ к Flowable, нам нужно представить нашу реализацию контроля разрешений.

Вариант первый

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

Уведомление:

  • Совместимость структуры данных
  • Согласованность данных, обновление данных о разрешениях необходимо уведомлять или данные о разрешениях регулярно извлекаются

Вариант 2

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

Возьмите LDAP в качестве примера, просто используйте правильный конфигуратор IDM при его использовании:

// 只需改动这一行的配置器即可
IdmEngineConfigurator idmEngineConfigurator = new LDAPConfigurator();
cfg.setIdmEngineConfigurator(idmEngineConfigurator);
    
ProcessEngine processEngine = cfg.buildProcessEngine();
IdmIdentityService idmIdentityService = idmEngineConfigurator.getIdmEngineConfiguration().getIdmIdentityService();
выполнить

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

  • Настройте параметр IdmEngineConfiguration.
  • Реализовать IdmIdentityService, который может наследовать IdmIdentityServiceImpl.
  • Реализовать UserQuery, который может наследовать UserQueryImpl
  • Реализовать GroupQuery, который может наследовать GroupQueryImpl
  • Реализовать PrivilegeQuery, который может наследовать PrivilegeQueryImpl

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

резюме

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

  • Если вы импортируете свои собственные данные системы разрешений в таблицу Flowable, это эквивалентно управлению двумя разрешениями в распределенной системе: одному для Flowable и одному для вашего собственного управления разрешениями.
  • Когда служба управления правами уже существует, она в основном используется клиентами.Использование части управления правами Flowable в качестве собственного клиента управления правами больше соответствует распределенному дизайну.Только одна система в распределенной системе предоставляет один тип службы для Другие системы используют
  • Что касается LDAP, то это тоже решение по управлению правами.Если есть LDAP внутри, можно использовать LDAP напрямую.Если LDAP нет, то не проблема написать соответствующий код для доступа к собственной системе управления правами.
Категории