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

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.
Керування доступом на основі ролей (англ. Role Based Access Control, RBAC) — розвиток політики вибіркового керування доступом, при якому права доступу суб’єктів системи на об’єкти групуються з урахуванням специфіки їх застосування, утворюючи ролі.

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

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

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

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

1.1. Визначення ролей посадових осіб та осіб-отримувачів послуг реєстру

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

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

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

Для розмежування прав доступу на рівні бізнес-процесів, необхідно описати їх у відповідних файлах (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 буде згенеровано три авторизації:

  • 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 — тільки для другого.

1.3. Розмежування прав доступу на рівні моделі даних (XML-шаблон)

<changeSet id="roles" author="registry owner">
    <comment>SET PERMISSIONS</comment>
    <ext:rbac>

        <ext:role name="isAuthenticated">
            <ext:table name="person">
                <ext:column name="first_name" read="true"/>
                <ext:column name="last_name" read="true"/>
            </ext:table>
        </ext:role>

        <ext:role name="officer" realm="officer_realm">
            <ext:table name="person">
                <ext:column name="first_name" read="true" update="true"/>
                <ext:column name="last_name" read="true" update="true"/>
                <ext:column name="passport" read="true"/>
            </ext:table>
        </ext:role>

        <ext:role name="officer_realm.passport_officer">
            <ext:table name="person">
                <ext:column name="passport" update="true"/>
            </ext:table>
        </ext:role>

        <ext:role name="inn_officer" realm="officer_realm">
            <ext:table name="person">
                <ext:column name="inn" update="true"/>
            </ext:table>
        </ext:role>

        <ext:role name="officer_realm.birth_officer">
            <ext:table name="person" insert="true"/>
        </ext:role>

        <ext:role name="death_officer" realm="officer_realm">
            <ext:table name="person" delete="true"/>
        </ext:role>

    </ext:rbac>
</changeSet>

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

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

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

userTasks

  • Citizen Sign Task — використовується для визначення задачі, що потребує підпису (КЕП) особи-отримувача послуг. Така задача може бути доступна тільки ініціатору бізнес-процесу.

  • Officer Sign Task — використовується для визначення задачі, що потребує підпису (КЕП) посадової особи.

  • User form — використовується для визначення задачі, що не потребує підпису (КЕП).

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

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

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

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

Для використання ${initiator} для задач та зокрема задач, що потребують підпису особи-отримувача послуг, у стартовій події (event) бізнес-процесу необхідно визначити ініціатора зі значенням `initiator`.

initiator

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

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

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

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

Оскільки запити до платформи (фабрики) даних відправляються від імені користувача, то треба бути уважним при моделюванні такого запита, адже користувач повинен мати доступ до запитуваних даних.

У Camunda-моделері передача токена виглядає наступним чином:

xAccessToken

Джерелом токена для делегатів-конекторів до фабрики є Ceph-документ окремої виконаної користувацької задачі.

Тобто користувач, задача якого була використана як джерело токена, повинен мати роль, для якої налаштований доступ до запитуваного ресурсу (див. Resource : 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.

2.3. Приклади моделювання із 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