Моделювання бізнес-процесів за умови підтримки розмежування прав доступу (RBAC)

Сторінка технічної документації є баченням майбутньої реалізації, актуальність якого може бути застарілою.

Розмежування прав доступу до даних

Більше про саму підтримку розмежування прав доступу на рівні фізичної моделі тут.

Налаштування ролей та прав доступу

Перед моделюванням бізнес-процесів треба для початку треба встановити які є ролі у модельованому реєстрі та визначити їх у Gerrit репозиторії реєстру:

Після встановлення та визначення ролей у відповідних файлах, можна розмежовувати права доступу та описати їх у визначених файлах:

Після розмежування ролей та прав доступу, можна переходити до моделювання бізнес-процесу.

Визначення ролей чиновників/громадян

Для того, щоб визначити ролі чиновників/громадян треба їх описати у відповідних файлах (roles/officer.yml, roles/citizen.yml), які являють собою список ролей, у форматі:

roles:
  - name: officer-1
    description: 'Перша роль чиновника'
  - name: officer-2
    description: 'Друга роль чиновника'
Імена ролей повинні бути написані латиницею та виключно у нижньому регістрі.

Розмежування прав доступу на рівні бізнес-процесів

Для розмежування прав доступу на рівні бізнес-процесів треба описати їх у відповідних файлах (bp-auth/officer.yml, bp-auth/citizen.yml) у форматі:

authorization:
  realm: 'officer'
  process_definitions:
    - process_definition_id: first-business-process
      process_name: "Ім'я першого процесу"
      process_description: 'Опис першого процесу'
      roles:
        - officer-1
    - process_definition_id: second-business-process
      process_name: "Ім'я другого процесу"
      process_description: 'Опис другого процесу'
      roles:
        - officer-1
        - officer-2
Імена ролей, реалм та process_definition_id повинні бути написані латиницею

Таким чином у Camunda буде згенеровано 3 авторизації:

  • READ, CREATE_INSTANCE для ролі/групи officer-1 для процесу first-business-process

  • READ, CREATE_INSTANCE для ролі/групи officer-1 для процесу second-business-process

  • READ, CREATE_INSTANCE для ролі/групи officer-2 для процесу second-business-process

Тобто роль officer-1 матиме доступ до старту обох процесів, а officer-2 тільки для другого.

Моделювання бізнес-процесів

Розмежування прав доступу на виконання задач бізнес-процесу

У Camunda є можливість розмежування прав доступу на окремі задачі. Для цього треба в Camunda Modeler обрати один з можливих element-template:

userTasks

  • Citizen Sign Task — використовується для визначення підписуючої задачі людини (може бути доступна тільки ініціатору бізнес-процесу)

  • Officer Sign Task — використовується для визначення підписуючої задачі чиновника

  • User form — використовується для визначення не підписуючої (звичайної) задачі

У випадку якщо було обрано підписуючу задачу чиновника або звичайну задачу у шаблоні є 3 поля для надання прав доступу до задачі

  • Assignee — може бути ${initiator}, (щоб заасайнити задачу одразу на користувача, що ініціював бізнес-процес) або ідентифікатор користувача (для того, щоб заасайнити задачу на одного чітко визначеного користувача)

Ідентифікатором користувача є preferred_user_name встановлений у Keycloak

Якщо було визначено Assignee, то наступні поля будуть зігноровані

Для використовування ${initiator} для задач та зокрема підписуючих задач людини у стартовому івенті бізнес-процесу має бути визначений ініцатор як initiator

initiator

  • Candidate users — список користувачів (написаних через кому) для яких задача доступна для виконання, в рамках бізнес-процесу кожен користувач може цю задачу заасайнити на себе та виконати

  • Candidate roles — список ролей (написаних через кому) для яких задача доступна для виконання, в рамках бізнес-процесу кожен користувач, що має хоча б одну з цих ролей може цю задачу заасайнити на себе та виконати (навіть якщо у нього немає доступу до самого бізнес-процесу, наприклад бізнес-процес bp1 може ініціювати лише користувач з роллю officer-bp1, хоча задачу в цьому бізнес-процесі, яка доступна ролі officer-task може виконати користувач лише маючи одну регламенту роль officer-task)

Candidate users та Candidate roles працюють в парі, бо на них тільки створюється авторизація у Camunda

Відповідність доступів користувачів до бізнес-процесу/задач та до фізичної моделі даних фабрики

Оскільки запити до Дата-Фабрики відправляються від імені користувача, то треба бути уважним при моделюванні такого запиту, так, як користувач має мати доступ до запитаних даних. У моделері передача токену виглядає так:

xAccessToken

Джерелом токену для делегатів-конекторів до фабрики є Ceph документ окремої виконаної користувацької задачі. Тобто користувач задача якого була використана як джерело токену повинен мати роль для якої налаштований доступ до запитаного ресурсу (registration на рисунку). Для того, щоб бути впевненим що користувач який виконує задачу має доступ до даних, треба змоделювати процес так, щоб використовувалась одна й та ж роль для дата-моделі та задачі.

Декілька прикладів:

  • У задачі Activity-shared-sign-app-include визначено Candidate Roles як officer-sign-app,officer-sing-app2 та токен з цієї задачі використовується для створення registration у фабриці. У цьому випадку обидві ролі officer-sign-app та officer-sing-app2 повинні мати доступ на створення registration.

  • У задачі Activity-shared-sign-app-include визначено Assignee як ${initiator} (з файлів bp-auth/officer.yml та bp-auth/citizen.yml відомо що ініціювати бізнес-процес можуть ролі officer-1, officer-2 та officer-3) та токен з цієї задачі використовується для створення registration у фабриці. У цьому випадку всі ролі що мають доступ до ініціювання цього бізнес-процесу (officer-1, officer-2 та officer-3) повинні мати доступ на створення registration.

Приклади моделювання із RBAC

Припустимо, що для моделювання бізнес-процесу із RBAC існує функція completer, що повертає дані про користувача, що виконав задачу

Синтаксис - ${completer('task_definition_id')} де 'task_definition_id' це task_definition_id виконаної задачі

completer повертає структуру:

{
  "userId": "completer_user_id",
  "accessToken" : "accessToken as encoded string"
}

Також припустимо, що при старті бізнес-процесу створюється об’єкт initiator що має таку ж структуру що й completer та усі інпут-параметри інтеграційних делегатів та усі інпут-параметри де фігурують completer або initiator є transient

Моделювання ситуації, коли дані з фабрики потрібні після виконання задачі користувачем:

data connector after user task

Моделювання ситуації, коли дані з фабрики потрібні перед виконанням першої задачі яка розподілена на ініціатора бізнес-процесу:

data connector after start event

Моделювання ситуації, коли дані з фабрики потрібні перед виконанням задачі:

data connector before user task with right access

У цьому випадку треба змоделювати проміжну задачу, яка дасть можливість зчитати токен з потрібним доступом

intermediate task example