Федеративна AAI в EOSC: архітектура та вимоги до EOSC Nodes

EOSC AAI Architecture 2025 визначає початкову архітектуру та технічні вимоги для федеративної автентифікації й авторизації між EOSC Nodes. Її основні завдання — забезпечити Single Sign-On між вузлами та підтримати наукові робочі процеси, що використовують ресурси кількох EOSC Nodes (вузлів EOSC) . Документ орієнтований на практичну реалізацію федерації за допомогою технологій, доступних сьогодні, водночас довгостроковою метою залишається перехід до динамічної full-mesh архітектури без центрального компонента.

Статус AAI у EOSC Federation у 2026 році

У другій редакції EOSC Federation Handbook, опублікованій у січні 2026 року, federated AAI визначена як FC-1 — обов'язкова Federating Capability EOSC Federation. Кожний EOSC Node (вузол EOSC) повинен мати щонайменше один Infrastructure Proxy, через який його сервіси інтегруються з федеративною AAI. Сервіси не приєднуються безпосередньо до EOSC Federation: вони спочатку включаються до відповідного EOSC Node.

У 2026 році Federated AAI Working Group продовжує розвиток цієї архітектури. Наступна версія EOSC AAI Architecture v2026 запланована як результат роботи групи на Q4 2026.

1) Яку задачу вирішує федерація автентифікації та авторизації

Федерація має забезпечити єдиний вхід користувача у сервіси різних нод, спільний базовий шар ідентичностей для сервісів, підтримку доступу до прикладних інтерфейсів і робочих процесів на основі маркерів доступу, а також узгоджені правила довіри, безпеки і обробки персональних даних.

Кінцева ціль описується як повнозв’язна федерація, але на першому етапі обрана практична модель із центральним вузлом і підключеними нодами. На початковому етапі побудови EOSC AAI Federation роль спільного Identity and Trust Layer виконує MyAccessID. Така централізована схема є проміжною практичною реалізацією; довгостроковою метою EOSC залишається full-mesh dynamic topology без центрального компонента.

2) Як працює перший етап і яку роль має нода

У моделі з центральним вузлом кожна нода підключає власний інфраструктурний проксі (Infrastructure Proxy) до центрального хаба MyAccessID як клієнт протоколу OpenID Connect. Нода отримує з центрального вузла єдину ідентичність користувача та можливість перевіряти маркери доступу, видані іншими нодами, а рішення про доступ до конкретних ресурсів реалізує локально через власні політики, ролі та квоти.

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

3) Мінімальні архітектурні вимоги до ноди НАН України

Документ прямо формулює вимогу наявності інфраструктурного проксі для кожної ноди. Такий проксі має реалізувати опорну архітектуру AARC Blueprint Architecture, має бути зареєстрований у реєстрі федерації як окремий клієнт, і має бути підключений до центрального хаба MyAccessID.

Додатково допускається використання одного або кількох механізмів керування спільнотами (Community AAI), якщо нода хоче керувати членством, групами та ролями дисциплінарних спільнот і видавати маркери доступу, які мають прийматися іншими нодами через центральний хаб.

4) Вимоги до протоколів інтеграції між нодами

Для взаємодії між нодами обов’язковими є протоколи OAuth 2.0 та OpenID Connect. Протокол Security Assertion Markup Language версії 2.0 не підтримується для міжнодової взаємодії (він може залишатися у локальних інтеграціях, але для міжнодових сценаріїв потрібен шлюз або проксі-перетворення).

5) Ключові технічні вимоги до інфраструктурного проксі ноди

Інфраструктурний проксі ноди має працювати як клієнт OpenID Connect центрального хаба, використовувати механізм автоматичного отримання параметрів підключення (OpenID Connect Discovery) та застосовувати сучасний сценарій входу через код авторизації із додатковим підтвердженням ключа. Документ вимагає застосування одноразового випадкового параметра для захисту від повторного відтворення запитів та забороняє небезпечні сценарії, у яких маркер доступу повертається у вебадресі перенаправлення.

Окремо визначена вимога перевірки маркерів доступу через механізм інспекції маркерів та через профіль «проксійованої інспекції», який є ключовим для перевірки маркерів, виданих іншими нодами. Для цього мають використовуватися конфіденційні клієнти (із секретом клієнта або взаємною транспортною аутентифікацією на основі сертифікатів) і має бути визначена політика кешування результатів перевірки маркерів.

Проксі також має вміти запитувати і передавати у внутрішні сервіси потрібні атрибути користувача, включно з атрибутами, що описують права доступу у стандартному форматі.

6.) AAI та каталоги ресурсів

AAI вирішує інше завдання, ніж EOSC Resource Catalogue. Research Product Catalogue і Service Catalogue забезпечують виявлення ресурсів, тоді як federated AAI забезпечує автентифікацію користувача та контроль доступу до ресурсів, для яких такий контроль потрібний. Разом ці механізми утворюють базовий технічний рівень участі EOSC Node у федерації.

Далі пропозиції для обговорення створення в НАН Україні Community AAI

1) Вимоги до керування спільнотами (якщо НАН України створює Community AAI)

Якщо нода НАН України створює власні механізми керування дисциплінарними спільнотами, такі платформи повинні працювати як сервер авторизації OAuth 2.0 і постачальник ідентичностей OpenID Connect, бути підключеними до центрального хаба, підтримувати автоматичне оприлюднення параметрів підключення, застосовувати безпечний сценарій входу через код авторизації, підтримувати перевірку маркерів, забороняти небезпечні сценарії входу, та експортувати групи і ролі у стандартному форматі прав доступу. Документ також рекомендує публікувати перелік колаборацій або проєктів із їхніми просторами назв для ролей і груп, статусами та юрисдикціями у людино-читаній і машинно-читаній формі.

2) Реєстрація EOSC Node (вузол EOSC) НАН України у реєстрі федерації

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

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

3) Які атрибути користувача нода має приймати і використовувати

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

4) Вимоги до безпеки і реагування на інциденти

Для участі у федерації нода має підтримувати узгоджені процедури реагування на інциденти, мінімальні вимоги до безпечної експлуатації та правила обробки персональних даних. Практично це означає, що вузол НАН України повинна мати визначену команду або відповідальну контактну особу для реагування на інциденти, а також підготовлені політики і регламенти, які підтверджують виконання цих вимог.

5) Практичні наслідки для майбутнього EOSC Node НАН України

Для проєкту побудови EOSC Node НАН України вимоги EOSC AAI Architecture 2025 визначають набір робіт, що охоплює AAI-інфраструктуру вузла, керування ідентичностями й атрибутами, політики безпеки та інтеграцію сервісів.

AAI infrastructure

Спроєктувати та розгорнути Infrastructure Proxy вузла відповідно до AARC Blueprint Architecture і вимог EOSC AAI та забезпечити його інтеграцію з MyAccessID, який у поточній реалізації EOSC AAI виконує роль спільного Identity and Trust Layer федерації.
Визначити потребу в Community AAI для керування групами, ролями та спільнотами користувачів. Якщо така функціональність необхідна, забезпечити її сумісність із протоколами та моделлю атрибутів EOSC AAI.

Identity & attributes

Визначити набір атрибутів, ідентифікаторів, груп і ролей, необхідних сервісам вузла, та реалізувати їх mapping до локальних моделей авторизації репозитаріїв, хмарних і обчислювальних ресурсів, порталів та інших сервісів.
Забезпечити коректне отримання, перевірку та використання OIDC/OAuth2 tokens і claims сервісами вузла відповідно до вимог EOSC AAI.

Policies & security

Підготувати необхідні відомості, endpoints, контакти технічної підтримки й безпеки та посилання на політики, потрібні для реєстрації й операційної інтеграції AAI вузла з EOSC Federation.
Узгодити політики інформаційної безпеки та захисту персональних даних із вимогами EOSC AAI, включно з процедурами повідомлення про інциденти, взаємодії з федеративними security contacts та реагування на інциденти.

Service integration

Інтегрувати сервіси вузла з Infrastructure Proxy, використовуючи передбачені EOSC AAI протоколи та endpoints, і забезпечити коректну передачу ідентичності та авторизаційних атрибутів до сервісів.
Забезпечити Single Sign-On для користувачів між сервісами вузла та підтримку міжвузлових сценаріїв, у яких користувач отримує доступ до ресурсів кількох EOSC Nodes.
Перевірити повний authentication/authorisation flow: вхід користувача, перенаправлення між сервісом, Infrastructure Proxy та Identity and Trust Layer, отримання і перевірку токенів і застосування локальних правил доступу.

Testing & operation

Провести інтеграційне тестування Infrastructure Proxy спочатку з тестовим, а потім із production-середовищем EOSC AAI.
Перевірити типові сценарії доступу: користувач власної установи, користувач іншого EOSC Node, член окремої research community та доступ до сервісу з рольовими обмеженнями.
Визначити відповідальних за експлуатацію Infrastructure Proxy, оновлення конфігурації, керування ключами й сертифікатами, моніторинг та реагування на AAI-інциденти.