Розмежування прав доступу на рівні ролей

Вступ

Lowcode-платформа повинна унеможливити неавторизований доступ до системи в процесі використання Кабінетів посадової особи та особи-отримувача послуг. Окрім цього, адміністратор регламенту повинен мати можливість налаштування прав доступу на рівні бізнес-процесів та створення ролей для регламенту.

Ролі

auth roles deployment

Типи ролей

Доступ до функціональності Платформи для ролей Посадова особа та Особа-отримувач послуг надається виключно через Kong API Gateway.

Кожний запит повинен бути заздалегідь автентифікований Сервісом управління ідентифікацією та доступом Keycloak. В залежності від контексту запита, автентифікація виконується в реалмі[1] officer або citizen.

Обліковий запис користувача може мати одну чи декілька ролей.

Ролі розподіляються на 3 групи:

1) Системні — створюються в процесі розгортання Платформи та надаються за замовчуванням користувачам відповідного реалму.

Ця група включає наступні типи ролей:

  • officer для реалму Посадова особа;

  • citizen для реалму Особа.

Видалення системних ролей може призвести до неконсистентного[2] стану системи.

2) Системні ролі суб’єкта — ролі, які відображають категорію громадянина.

До такої групи належать наступні типи:

  • individual;

  • entrepreneur;

  • legal;

  • unregistered_individual;

  • unregistered_entrepreneur;

  • unregistered_legal.

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

Детальніше про категорії громадян можна дізнатися за посиланням.

3) Регламентні — ролі, які є частиною регламенту та створються в процесі публікації змін до регламенту.

Наявність системних ролей відповідає за доступ до системи в цілому. Тобто, cервіс управління задачами користувача та Сервіс управління бізнес-процесами користувача надають доступ до ресурсів тільки за наявності ролі officer або citizen.

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

Мапінг[3] ролей

Модель авторизації Camunda BPMN Engine використовує групи для налаштування спільних правил доступу до ресурсів. В процесі запита до Сервісу виконання бізнес-процесів, виконується зіставлення ролей, що є в токені, з групами в Camunda. Тобто, якщо користувач має роль officer-first-rank, яка була надана йому у Keycloak, то при виконанні запита він отримує права доступу, що належать групі officer-first-rank у Camunda BPMN Engine.

Діаграма послідовності процесу авторизації

Diagram

Запуск бізнес-процесу

auth camunda group auth

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

  • Користувач повинен мати налаштовану роль у Keycloak, яка матиме відповідну групу в Camunda.

  • Група в Camunda повинна мати налаштовані правила авторизації для відповідного бізнес-процесу (Process definition authorization). Приклад:

Type Group Permissions Resource Id

Allow

officer-first-rank

READ, CREATE_INSTANCE

add-lab

  • Група в Camunda має налаштовані правила авторизації для створення нових екземплярів бізнес-процесів (Process instance authorization). Приклад:

Type Group Permissions Resource Id

Allow

officer-first-rank

CREATE

*

Корисні посилання

Camunda Start Process Permission

Примітки

1. Realm — це концепція в Keycloak, яка відноситься до об’єкта, що керує набором користувачів, а також їхніми обліковими даними, ролями та групами.
2. Консистентність (англ. — data consistency) — узгодженість даних.
3. Мапінг — визначення відповідності даних між потенційно різними семантиками одного об’єкта або різних об’єктів.