Міжреєстрова взаємодія без "Трембіта"
Задля зменшення надлишкового використання обчислювальних потужностей, зовнішнього трафіку та часу відповіді при інтеграції між реєстрами без використання "Трембіта". Виділяється три сценарії використання інтероперабельності реєстрів.
-
За умови що реєстри належать одному клієнту, є спорідненими (Група реєстрів)
-
Реєстри знаходяться на одній платформі належать різним клієнтам (Інтеграція на рівні платформи)
-
Інтеграція з сторонніми системами
1. Група реєстрів
Для реєстрів, що належать до одного клієнта використовується додатково створений спільний realm але окремі client в
Keycloak для Kong. Спільний realm використовується як identity provider для realm-ів реєстрів цієї групи, тобто створення користувачів, керування ролями відбувається в спільному груповому realm-і, а не в realm-ах окремих реєстрів. Таким чином забезпечується можливість створення спільних користувачів і таким же чином забезпечується можливість доступу до даних через API.
Конфігурація та вибір realm відбувається на рівні розгортання реєстру в Control Plane через абстракцію RegistryGroup. Будь-який реєстр може належати тільки до однієї групи. Створений реєстр не може бути включений до групи
RegistryGroup - являє собою окремий K8s ресурс який зберігає в собі комбінацію назв realm-ів.
2. Інтеграція на рівні платформи
2.1. Загальний опис
Реєстр клієнт - реєстр який використовує дані з іншого реєстру.
Реєстр тримач даних (цільовий реєстр) - реєстр який надає доступ до даних які зберігаються у ньому.
2.1.1. Інтеграція на рівні кабінетів
Інтеграція відбувається через окремий ресурс Kong реєстру клієнта. Аутентифікація проводиться через OIDC plugin у відповідних реалмах реєстру клієнта.
2.1.2. Інтеграція на рівні бізнес процесів
Виклик бізнес процесу іншого реєстру можливий тільки з бізнес процесу реєстру клієнта.
2.2. Моделювання
2.2.1. Реєстр тримач даних
Надання доступу до існуючих searchConditions здійснюється за допомогою тега exposeSearchCondition на підставі якого генерується карта доступів в Istio VirtualService-і
<ext:exposeSearchCondition name="search-condition-name" trembita="true" platform="true" externalSystem="true"/>Надання доступу до бізнес процесів відбувається по аналогії з інтеграції з Трембіта на підставі якої конфігурується карта доступів в Istio VirtualService-і
2.2.2. Реєстр клієнт даних
Для побудови інтеграції необхідно на бізнес процесі або на формі кабінету зробити запит до platform gateway
http://registry-url/api/integration/data-factory/{master-registry}/{search-condition}registry-url - публічний URL реєстру
http://platform-gateway/data-factory/{master-registry}/{search-condition}platform-gateway - внутрішне DNS ім’я Platform Gateway реєстру клієнта
2.3. Загальний flow
GET /api/integration/mon-school/get-available-schools HTTP/1.2
...
Client: MON-CHILD
Cookie: session=gyMTQk_shwcQxQ6WqBXtmw...
Cookie: session2=gyMTQk_shwcQxQ6WqBXtmw...
Cookie: session3=gyMTQk_shwcQxQ6WqBXtmw...
...GET /api/integration/mon-school/get-available-schools HTTP/1.2
...
Client: MON-CHILD
x-access-token: JWT token
...Platform Gateway - є окремим компонентом на основі Spring Cloud Gateway з вбудованими фільтрами для динамічної підміни JWT токенів в залежності від вхідних параметрів запиту.
3. Інтеграція з сторонніми системами
Створення користувача, виставлення бізнес процесів та точок інтеграції Дата Фабрики відбувається за тим самим принципом, що і для інтеграції на рівні платформи. Відмінність полягає в тому, що аутентифікація і ротація токенів покладається на систему, а аутентифікація запитів на Kong проводиться за допомогою JWT plugin замість OIDC plugin-a.