Target Architecture of the EOSC Authentication and Authorisation Federation

At the EOSC Symposium, in a presentation by Bob Jones, EOSC-A / CERN, on 3 November 2025, a consensus was described regarding technical requirements, including the requirements for a federated AAI EOSC Node as defined in the EOSC AAI Architecture 2025.

The document describes the target architecture and the first implementation phase of the Authentication and Authorisation Federation of the European Open Science Cloud. This federation is intended to connect all Nodes into a single access space for services and data.

1) What problem does the Authentication and Authorisation Federation solve?

The federation is intended to provide single sign-on for users across services of different Nodes, a shared baseline identity layer for services, support for access to application interfaces and workflows based on access tokens, and agreed rules for trust, security and personal data processing.

The final objective is described as a full-mesh federation. However, at the first stage, a practical model with a central hub and connected Nodes has been selected. The central hub is implemented through the MyAccessID service, which acts as the central hub and baseline identity layer.

2) How the first phase works and what role a Node has

In the central-hub model, each Node connects its own Infrastructure Proxy to the MyAccessID central hub as an OpenID Connect client. The Node receives a unified user identity from the central hub and gains the ability to validate access tokens issued by other Nodes. Decisions on access to specific resources are implemented locally through the Node’s own policies, roles and quotas.

For the National Academy of Sciences of Ukraine, this means that the NASU Node is considered a separate logical Node with its own set of services, such as repositories, computing resources, cloud services and other components. It connects to the federation through an Infrastructure Proxy and, where necessary, may support separate community management mechanisms for specific disciplines.

3) Minimum architectural requirements for the NASU Node

The document explicitly formulates the requirement that each Node must have an Infrastructure Proxy. This proxy must implement the reference AARC Blueprint Architecture, be registered in the federation registry as a separate client, and be connected to the MyAccessID central hub.

In addition, the use of one or more Community AAI mechanisms is allowed if the Node wishes to manage membership, groups and roles for disciplinary communities and issue access tokens that must be accepted by other Nodes through the central hub.

4) Requirements for integration protocols between Nodes

OAuth 2.0 and OpenID Connect are mandatory protocols for interaction between Nodes. Security Assertion Markup Language version 2.0, or SAML 2.0, is not supported for inter-Node interaction. It may remain in local integrations, but inter-Node scenarios require a gateway or proxy-based conversion.

5) Key technical requirements for the Node Infrastructure Proxy

The Node Infrastructure Proxy must operate as an OpenID Connect client of the central hub, use OpenID Connect Discovery for the automatic retrieval of connection parameters, and apply the modern authorisation code flow with Proof Key for Code Exchange, or PKCE.

The document requires the use of a one-time random parameter to protect against replay attacks and prohibits insecure scenarios in which an access token is returned in the redirect URL.

A separate requirement is defined for access token validation through token introspection and through the proxied introspection profile, which is essential for validating tokens issued by other Nodes. This requires the use of confidential clients, either with a client secret or with mutual transport authentication based on certificates. A policy for caching token validation results must also be defined.

The proxy must also be able to request and transmit to internal services the required user attributes, including attributes that describe access rights in a standard format.

Further proposals for discussing the creation of a Community AAI in NASU

1) Requirements for community management if NASU creates a Community AAI

If the NASU Node creates its own mechanisms for managing disciplinary communities, such platforms must operate as an OAuth 2.0 authorisation server and an OpenID Connect identity provider. They must be connected to the central hub, support the automatic publication of connection parameters, apply the secure authorisation code flow, support token validation, prohibit insecure login flows, and export groups and roles in a standard entitlement format.

The document also recommends publishing the list of collaborations or projects, including their namespaces for roles and groups, statuses and jurisdictions, in both human-readable and machine-readable form.

2) Registration of the NASU Node in the federation registry

To connect to the federation, a Node must be registered in the relevant registry and provide a minimum set of information. This includes the Node name and description, website, legal information about the operating organisation, technical support contacts, security contacts, technical parameters, including redirect URIs for the Infrastructure Proxy and OpenID Connect metadata for community management services, namespaces for groups and roles, and links to usage and data protection policies.

The document also requires declarations of compliance with codes of conduct and baseline requirements covering personal data protection, incident response and minimum rules for secure operation.

3) Which user attributes the Node must accept and use

The document profiles a set of attributes that must be available within the federation. For the practical implementation of the NASU Node, the key attributes are: a persistent globally unique user identifier, first name and last name, contact email address, institutional domain, affiliation type, level of identity assurance, and group and role attributes in a standard format.

The Node must configure the mapping of these attributes to local accounts, groups, roles and quotas. Where necessary, the level of assurance may also be used as a condition for access to sensitive resources.

4) Requirements for security and incident response

To participate in the federation, a Node must support agreed incident response procedures, minimum requirements for secure operation, and rules for personal data processing.

In practice, this means that the NASU Node must have a designated team or responsible contact person for incident response, as well as prepared policies and procedures confirming compliance with these requirements.

5) How to turn the document’s requirements into a work plan for the NASU Node

For the project of building the NASU Node, the requirements of the document can logically be transformed into a set of work packages covering infrastructure, policies and the practical integration of services.

The Node Infrastructure Proxy must be designed and deployed, and its integration with MyAccessID as the central hub must be configured.

It is necessary to determine whether community management mechanisms are required and, if so, to prepare a platform that meets the requirements for protocols, token validation and the representation of roles and groups in a standard format.

A complete package of data and links to policies must be prepared for registering the Node in the federation registry, including technical support contacts and security contacts.

Security and personal data protection policies must be aligned with federation requirements, including incident response procedures.

The mapping of user attributes and access rights into the Node’s internal services must be described and implemented, including repositories, cloud services, computing resources and portals.

A clear user login scenario must be provided, together with correct user redirection to the federation’s baseline identity layer in inter-Node scenarios.