Розмежування доступу зовнішніх систем до API бізнес процесів

Загальний опис

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

Актори та ролі користувачів

  • Технічний адміністратор реєстру

  • Моделювальник реєстру

  • Зовнішні системи

Функціональні сценарії

  • Створення ролей для зовнішніх систем

  • Застосування ролей до сервісних акаунтів Кіклока

  • Керування доступом зовнішньої системи до окремих бізнес процесів через Трембіту

  • Керування доступом зовнішньої системи до окремих бізнес процесів без Трембіти

Поточна реалізація

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

  • прописати бізнес-процеси, доступні для зовнішніх систем, у файлі /bp-trembita/external-system.yml.

Приклад файлу регламенту
trembita:
  process_definitions:
    - process_definition_id: 'some-bp'
      start_vars:
        - edrpou
      return_vars: []

  • прописати необхідні авторизації для зовнішніх систем, у файлі /bp-auth/external-system.yml.

Приклад файлу регламенту
authorization:
  realm: 'external-system'
  process_definitions:
    - process_definition_id: 'some-bp'
      process_name: "Створення нової школи з підписом за замовченням"
      process_description: "Створення нової школи з підписом за замовченням"
      roles:
        - 'trembita-invoker'

У полі roles моделювальник, найімовірніше, додасть лише роль trembita-invoker, оскільки вона є дефолтною для усіх зовнішніх систем

Сценарій через Трембіту

Для запитів через Трембіту у Кіклоці створюється окремий клієнт trembita-invoker у рілмі external-system.

Трембіта підтримує налаштування прав доступу для підсистем на рівні SOAP-ендпоінту. Приклад налаштування для пошукових запитів.

Через bp-webservice-gateway наразі виставляється 1 соап ендпоінт start-bp

Сніпет згенерованого wsdl
<wsdl:portType name="BpWebservice">
    <wsdl:operation name="startBp">
        <wsdl:input message="tns:startBpRequest" name="startBpRequest"> </wsdl:input>
        <wsdl:output message="tns:startBpResponse" name="startBpResponse"> </wsdl:output>
    </wsdl:operation>
</wsdl:portType>

Внаслідок цього, зараз на рівні Трембіти існує можливість налаштувати для клієнта лише доступ до ендпоінта startBp, через який клієнт має можливість викликати будь-який бізнес процес, позначений в регламенті як доступний для external-system.

Сценарій через API без Трембіти

Для запитів без Трембіти на рівні Контрол Плейну необхідно налаштувати інтеграцію з типом Зовнішня система

cp ext system config
Figure 1. Скріншот налаштованої системи

В результаті для кожної налаштованої зовнішньої системи у Кіклоці створюється сервісний акаунт з дефолтною роллю trembita-invoker.

Розмежування доступів у даному сценарії відбувається саме на рівні окремих сервіс акаунтів.

Адміністратор реєстру має можливість вручну створити додаткові ролі, необхідні для розмежування доступу різних зовнішніх систем, та призначити ці ролі відповідним сервіс акаунтам. В такому випадку адміністратор повинен через Camunda Cockpit налаштувати необхідні авторизації для бізнес процесів, щоб гранулярно керувати доступом різних ролей.

Можливість створити ролі вручну і прописати необхідні авторизації на рівні регламенту - забороняється Утилітою валідації регламенту.

Через bp-webservice-gateway наразі виставляється 1 REST-ендпоінт /start-bp, що не є проблемою для сценарію розділення доступів, але може завадити встановлювати інші обмеження (наприклад, в такому сценарії неможливо використати url-based рейт-лімітинг і обмежити кількість запитів до одного бізнес процесу однією зовнішньою системою)

Загальні принципи та положення

  • Для обох сценаріїв виклику БП зовнішніми системами повинне існувати розділення на N ендпоінтів, кожен з яких використовується для запуску окремого БП

  • Старі ендпоінти залишаються для зворотньої сумісності та для використання у сценаріях, які не вимагають гранулярного керування запуском БП різними зовнішніми системами

  • Адміністратор регламенту повинен мати можливість вказувати необхідні ролі для зовнішніх систем у регламенті реєстру

  • Адміністратор реєстру керує ролями сервісних користувачів вручну

  • Для розмежування доступу до БП використовуються існуючі механізми авторизації

Високорівневий дизайн рішення

Генерація необхідних SOAP та REST ендпоінтів

Поточна імплементація bp-webservice-gateway не дозволяє порівняно просто розширити сервіс для динамічної генерації необхідних SOAP-ендпоінтів.

Усі необхідні класи для коректного створення wsdl-файлу та обробки вхідних запитів мають існувати на момент запуску застосунку.

Можливість динамічно створювати необхідні обробники, базуючись на контенті вхідного файлу /bp-trembita/external-system.yml, є важко здійснюваною.

У зв’язку з цим, кращою опцією є розширення існуючої утиліти service-generation-utility та генерація усього необхідного для bp-webservice-gateway коду на етапі публікації регламенту, за прикладом дата-сервісів rest-api, kafka-api і т.д.

Необхідні зміни для переносу створення SOAP-ендпоінтів до service-generation-utility

У bp-webservice-gateway

  • перейменувати репозиторій bp-webservice-gateway на bp-webservice-gateway-core-image

  • за прикладом rest-api-core-base-image залишити у bp-webservice-gateway-core-image код, який не потребує генерації

  • все, що стосується запуску застосунку (ресурси для хелм чарта, appliation.yaml, Main клас застосунку) перенести до service-generation-utility у папку resources/META-INF/templates/bp-webservice-gateway

У service-generation-utility

  • шаблонізувати необхідні для генерації SOAP-ендпоінтів ресурси

  • додати новий параметр --module=bp-webservice-gateway до виклику service-generation-utility

У registry-regulation-publication-pipeline

  • додати стейджі генерації, білда та деплою bp-webservice-gateway за прикладом дата-сервісів

  • на стейджі генерації викликати service-generation-utility з параметрами --module=bp-webservice-gateway -Dbp-trembita-external-file=/bp-trembita/external-system.yml

Очікуваний результат

Сніпет згенерованого wsdl
<wsdl:portType name="BpWebservice">
    <wsdl:operation name="startBp">
        <wsdl:input message="tns:startBpRequest" name="startBpRequest"> </wsdl:input>
        <wsdl:output message="tns:startBpResponse" name="startBpResponse"> </wsdl:output>
    </wsdl:operation>
    <wsdl:operation name="startBpSomeBp1">
        <wsdl:input message="tns:startBpSomeBp1Request" name="startBpRequest"> </wsdl:input>
        <wsdl:output message="tns:startBpSomeBp1Response" name="startBpResponse"> </wsdl:output>
    </wsdl:operation>
    <wsdl:operation name="startBpSomeBp2">
        <wsdl:input message="tns:startBpSomeBp2Request" name="startBpRequest"> </wsdl:input>
        <wsdl:output message="tns:startBpSomeBp2Response" name="startBpResponse"> </wsdl:output>
    </wsdl:operation>
</wsdl:portType>

Необхідні зміни для генерації REST-ендпоінтів

Буде створено новий ендпоінт

Приклад запиту і тіла
POST /start-bp/{process-definition-id}

{
    "start-variables": {}
}

Формат відповіді і обробка помилок залишаться такими ж, як і в існуючому ендпоінті /start-bp

Управління ролями сервісних користувачів

Для коректного та зручного управління ролями, необхідними для сервісних користувачів, необхідні:

  • розширення регламенту реєстру файлом /roles/external-system.yml

Можливий контент файлу
roles:
  - name: role-for-subsystem-in-business-group-1
    description: Available business processes 1, 2, 3
  - name: role-for-subsystem-in-business-group-2
    description: Available business processes 3, 4, 5

  • розширення пайплайну публікації регламенту (крок create-keycloak-roles) створенням ролей у рілмі external-system

За умови викидання даного пункту зі скоупу - розглянути можливість прибрати з валідації регламенту перевірки BpAuthToBpmnRoleExistenceValidator (перевірка валідності ролей, що використовуються у bp-auth)

Компоненти системи та їх призначення в рамках дизайну рішення

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

Підсистема Компонент Опис змін

Підсистема моделювання регламенту реєстру

service-generation-utility

Генерація необхідних SOAP-ендпоінтів і коду, що необхідний для запуску bp-webservice-gateway

Підсистема зовнішніх інтеграцій

bp-webservice-gateway

Обробка нових REST та SOAP-ендпоінтів

Підсистема моделювання регламенту реєстру

registry-regulations-publications-pipelines

Генерація та деплой bp-webservice-gateway, створення ролей для external-system рілма

Підсистема моделювання регламенту реєстру

registry-regulations-сli

Валідація нового файлу реєстру (або вимкнення існуючих валідацій для проходження пайплайну публікації)

Міграція

  • Додати до існуючих реєстрів /roles/external-system.yml

roles: []

  • Тригернути пайплайн публікації зміною файлу /bp-trembita/external-system.yml

Підтримка зворотної сумісності

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

Високорівневий план розробки

Технічні експертизи

  • BE

  • DevOps

Попередній план розробки

  1. зміни, необхідні для пересення генерації та деплою bp-webservice-gateway до пайплайну публікації

  2. Розширення регламенту створенням ролей для зовнішніх систем

  3. Розробка міграційних апгрейд-скриптів

  4. Інструкція розмежування доступу до API БП на рівні Трембіти (можливо, перевикористати інструкцію для розмежування доступу для критеріїв пошуку)

  5. Інструкція розмежування доступу до API БП без Трембіти