BRIDGING AUTHENTICATION FOR SERVICES IN THE VIRTUAL RESEARCH ENVIRONMENT

BRIDGING AUTHENTICATION FOR SERVICES IN THE VIRTUAL RESEARCH ENVIRONMENT Aug 2025 AUTHOR(S): Tomas Ondrejka Technical University of Denmark (DTU) SUPERVISOR(S): Enrique García García (IT-TC-LCG) Giovanni Guerrieri (IT-TC-LCG) CERN openlab Report 2025 TABLE OF CONTENTS 1 Introduction 3 2 Authentication Concepts 3 2.1 IdP........................................... 3 2.2 OAuth2.0....................................... 3 2.3 OpenID ........................................ 4 2.4 JWT.......................................... 4 3 Goals 4 3.1 Adoption of OAuth 2.0 / OIDC Standards . . . . . . . . . . . . . . . . . . . . . 4 3.2 Removal of Invenio Authentication Components . . . . . . . . . . . . . . . . . . 4 3.3 Unified JWT-Based Access Across All Interfaces . . . . . . . . . . . . . . . . . . 5 3.4 Stateless and Scalable Authorization Model . . . . . . . . . . . . . . . . . . . . 5 3.5 Foundation for Scope-Based Authorization . . . . . . . . . . . . . . . . . . . . . 5 3.6 Clarification of REANA Server Identity Responsibilities . . . . . . . . . . . . . . 5 4 Architecture and Implementation 5 4.1 REANA Server Auth Responsibility Model . . . . . . . . . . . . . . . . . . . . . 5 4.2 JWT Validation in the REANA Server . . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Mapping IdP Identities to REANA Users . . . . . . . . . . . . . . . . . . . . . . 7 4.4 Just-in-Time User Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.5 OAuth 2.0 Device Code Flow for the CLI . . . . . . . . . . . . . . . . . . . . . . 8 4.6 VRE–REANA Integration and Token Injection . . . . . . . . . . . . . . . . . . . 9 4.7 ImplementationPhases................................ 10 5 Future 11 6 Conclusion 11 BRIDGING AUTHENTICATION FOR SERVICES IN THE VIRTUAL RESEARCH ENVIRONMENT 1 CERN openlab Report 2025 ABSTRACT Scientific workflows span heterogeneous infrastructures and institutions, demanding secure, interoperable, and reproducible access. This project consolidates identity handling for the ESCAPE Virtual Research Environment and REANA by adopting standards-based authentication and authorization, unifying access on token-based mechanisms, and clarifying system responsibilities. The design yields a stateless architecture that integrates cleanly with standard identity providers, enhancing maintainability and deployment portability. BRIDGING AUTHENTICATION FOR SERVICES IN THE VIRTUAL RESEARCH ENVIRONMENT 2 CERN openlab Report 2025 1 Introduction Scientific analyses operate at scale, requiring coordinated data access, workflow execution, and reproducibility across diverse resources. The ESCAPE project [1] (European Science Cluster of Astronomy and Particle physics ESFRI research infrastructures) developed open-source tools and services for data-driven research across scientific domains. Within this framework, the Virtual Research Environment (VRE)[2] is a cloud-based, collaborative platform at CERN for European scientific communities. In this context, REANA [3] provides reusable, declarative workflow execution on remote compute backends, enabling analyses to be specified once and run reproducibly across infrastructures. Despite its functional maturity, REANA’s identity layer remained fragmented, increasing integration effort and limiting interoperability. This work streamlines REANA’s stack by adopting authentication and authorization standards, OAuth 2.0[4] and OpenID Connect[5], unifying access through a single token model, and clearly separating responsibilities so that authentication is client-driven and the server focuses solely on authorization. The resulting design reduces operational complexity and enables multi-institutional use. 2 Authentication Concepts 2.1 IdP An Identity Provider (IdP) is a trusted entity that creates, maintains, and manages user identities and provides authentication to relying applications (the relying parties). In practice, most Identity Providers implement OAuth 2.0 for delegated authorization and extend it with OpenID Connect for an identity layer; after successful authentication, they issue a JSON Web Token (JWT) with cryptographically signed claims about the subject. For example, the ESCAPE INDIGO IAM service [6] adopts this model, relying on OAuth 2.0, OIDC, and JWTs for identity and access management. Token issuance is a core IdP function. Tokens, typically JWTs, carry claims such, and optional attributes (e.g., roles, groups), enabling stateless, interoperable authentication and authorization without shared session state. In this work, the focus is on ESCAPE IAM, which issues OAuth 2.0/OIDC-compliant JWTs for the ESCAPE Virtual Research Environment, and on CERN’s Single Sign-On (SSO). 2.2 OAuth 2.0 OAuth 2.0 is an open standard for delegated authorization that lets a resource owner grant a third-party client controlled access to protected assets, without sharing credentials. The framework defines four roles: Resource Owner, Client, Authorization Server, and Resource Server; it also supports multiple flows for web, native, and limited-input environments. Relevant flows in this work are: •Authorization code flow: an intermediate code is exchanged for an access token. •Device code flow: designed for devices or CLI tools; the client obtains a device and user code, instructs the user to visit a verification URL on another device, and polls until the access token is issued [7]. OAuth 2.0 includes scope-based authorization (restricting token privileges), token-based access control (presenting tokens in HTTP requests, typically via the Authorization header), BRIDGING AUTHENTICATION FOR SERVICES IN THE VIRTUAL RESEARCH ENVIRONMENT 3 CERN openlab Report 2025 and protocol layering (authentication added via OpenID Connect). In this project, OAuth 2.0 underpins acquisition and use of JWT access tokens issued by ESCAPE IAM, ensuring secure, interoperable, and JWT-aware access to REANA services across web and commandline interfaces. 2.3 OpenID OpenID Connect (OIDC) is an identity layer atop OAuth 2.0 that adds standardized authentication, allowing clients to verify end-user identity and obtain profile information in an interoperable, REST-style manner. After successful authentication, the IdP issues an ID Token, typically a signed JWT, containing claims, authentication time, and optionally name or email; this ID Token is returned alongside the OAuth 2.0 access token. OIDC also defines two key endpoints. The UserInfo endpoint is a protected resource that returns standardized end-user claims when presented with an access token. The OpenID Provider Configuration document (e.g. escape.cloud.cnaf.infn.it/.well-known/openid-configuration) describes the IdP’s capabilities, supported flows, endpoints, signing keys via the JSON Web Key Set (JWKS) URI, and supported claims, enabling dynamic client discovery and configuration. 2.4 JWT A JSON Web Token is a compact, URL-safe representation of claims used widely in OAuth 2.0 and OpenID Connect to convey authentication and authorization data statelessly. A JWT comprises three base64url-encoded segments: header, payload, and signature, concatenated with dots. Two standard JWT claims are central to identity mapping and authorization (sub – user id within IdP, iss – token IdP itself). Depending on context, different token types are issued: an ID Token carrying identity claims (e.g., sub, name, email); an Access Token for protected resource access (may include authorization claims, scopes, and expiry); and a Refresh Token, long-lived and used to obtain new access tokens. JWT Verification keys are published by the IdP via a JWKS, discoverable at the jwks_uri advertised in the .well-known/openid-configuration endpoint of an IdP server. 3 Goals 3.1 Adoption of OAuth 2.0 / OIDC Standards Adopting OAuth 2.0 and OpenID Connect as REANA’s authentication/authorization foundation aligns the system with industry standards, enabling interoperability with institutional and federated IdPs under established trust frameworks and mature security models. Compliance spans standardized flows, claim sets, and discovery, ensuring consistent IdP interaction and straightforward integration by external services without bespoke logic. This eases client integration, and maintains compatibility across diverse identity stacks. 3.2 Removal of Invenio Authentication Components Removing Invenio-based authentication components reduces architectural complexity, and database overhead. It is currently significant, with roughly half of the schema devoted to auth/authz BRIDGING AUTHENTICATION FOR SERVICES IN THE VIRTUAL RESEARCH ENVIRONMENT 4 CERN openlab Report 2025 tables that Invenio maintains alongside endpoints and token storage. Delegating identity management to trusted IdPs streamlines REANA to its core purpose, yielding a smaller and more maintainable architecture. 3.3 Unified JWT-Based Access Across All Interfaces Originally, REANA relied on a mix of custom REANA tokens, GitLab tokens, and Flask session IDs, with Invenio sitting in the middle to manage these credentials and their mappings. This fragmented setup meant that different interfaces depended on different tokens. By moving to a single IdP-issued JWT, these layers are unified: the same token can be used across the web UI, CLI, and automation. Invenio is no longer required to mediate identities, and the flow simplifies to direct JWT validation against the trusted IdP, yielding a coherent and lightweight access-control model. 3.4 Stateless and Scalable Authorization Model A stateless authorization model places all authentication and authorization data in a JWT issued by a trusted Identity Provider, removing the need for shared session storage or auth users. Any REANA server instance can validate and authorize requests, simplifying the architecture and improving fault tolerance 3.5 Foundation for Scope-Based Authorization Establishing a claimand scope-aware authorization framework prepares REANA for advanced models such as Role-based access control (RBAC) and scope-based permissions. Relevant claims, roles, group memberships, and granted scopes, are extracted from JWTs issued by trusted IdPs and used to enforce policies that govern per-user access to resources and operations. 3.6 Clarification of REANA Server Identity Responsibilities Posing a clear separation of concerns for REANA’s identity management results in the delegation of authentication to trusted Identity Providers, while keeping authorization as a core server responsibility. 4 Architecture and Implementation 4.1 REANA Server Auth Responsibility Model In the prior design (Figure 1), REANA Server contained authentication redirects, handled callbacks/code exchange, managed sessions, and exposed authentication endpoints. As shown in Figure 2, the new model enables device code flows in environments without a graphical UI, significantly reducing complexity and therefore lowering latency. The REANA Server is restricted to authorization, while authentication is initiated by the user (browser/CLI) and performed directly against an IdP using OAuth 2.0/OIDC. The IdP issues a JWT to the client, which is presented to REANA; the server validates the signature via JWKS, checks key claims, and enforces authorization based on identity and roles, remaining agnostic to the token acquisition method. BRIDGING AUTHENTICATION FOR SERVICES IN THE VIRTUAL RESEARCH ENVIRONMENT 5 CERN openlab Report 2025 Figure 1: Previous REANA Server Auth Architecture Figure 2: New REANA Server Auth Architecture 4.2 JWT Validation in the REANA Server Authlib [8] has been selected for the project as it provides well-supported OAuth 2.0, OIDC, JWT, and JWK utilities, to underpin token validation while minimizing code churn. Rather than replacing existing hooks, we layered JWT authorization on the current design using a decorator that differentiates token types. The reana-server module extracts the Bearer token, retrieves IdP JWKS, and verifies the JWT signature and decodes the payload; then resolves the user by IdP identity (e.g., idp_id), performs JIT provisioning when necessary, and finally enforces authorization. BRIDGING AUTHENTICATION FOR SERVICES IN THE VIRTUAL RESEARCH ENVIRONMENT 6 CERN openlab Report 2025 4.3 Mapping IdP Identities to REANA Users REANA currently auto-generates user IDs that lack any reference to the IdP user, yet identity extraction relies on JWT claims, specifically the IdP user identifier in sub (and the issuer in iss). With the removal of the Invenio package, the previous IdP-to-REANA user ID mappings are no longer used, therefore identity resolution relies directly on the JWT claims. Two options were considered: creating a separate mapping table for (sub,iss) or adding sub and iss columns to the existing user table. The latter was selected for simplicity, acknowledging that a future multi-IdP setup would demand a more complex implementation (e.g., support for multiple trusted IdPs and verification against multiple JWK key sets). 4.4 Just-in-Time User Provisioning When a user accesses REANA for the first time, they may have no database entry, either because the IdP user identifier is not yet stored or because the user record has never been created. Onboarding used to rely on custom synchronization scripts that imported user data in advance, but this proved asynchronous and hard to scale. To address this, it was implemented Just-in-Time [9] (JIT) provisioning for REANA: on the first request that contains a valid JWT, the server extracts the IdP identity, queries the OpenID UserInfo endpoint for minimal profile data, creates the user, stores sub/iss, and then continues the processing of the request (Figure 3). Figure 3: JIT Provisioning BRIDGING AUTHENTICATION FOR SERVICES IN THE VIRTUAL RESEARCH ENVIRONMENT 7 CERN openlab Report 2025 4.5 OAuth 2.0 Device Code Flow for the CLI Historically, users supplied a token via an environment variable to CLI; the REANA team proposed moving to device code (Figure 4). With OAuth, the CLI, which is constrained interface environment, can authenticate using the device code flow, but the CLI must first discover which IdP a REANA deployment trusts. To avoid hardcoding reana-client IdP values, REANA Server provides a proxy to the IdP’s OpenID configuration. When the user runs the CLI login, the CLI queries REANA Server, obtains the device authorization URL (“device code URL”), token URL, and client_id, and then starts the device code flow against the appropriate IdP. This centralizes IdP configuration, supports multiple REANA setups, and replaces the ad-hoc token provisioning with a standard, user-friendly login (Figure 5). Figure 4: REANA Client Device Code Figure 5: REANA Client IdP Payload BRIDGING AUTHENTICATION FOR SERVICES IN THE VIRTUAL RESEARCH ENVIRONMENT 8