Traitements/données de différentes infrastructures Gaia-data

Traitements/données de différentes infrastructures Gaia-data

Identifiant

• Pôle: DINAMIS
• Contact: Rémi Cresson

Participants

• Un utilisateur Gaia Data
• Une infrastructure A de Gaia Data (ex: IDS pôle DINAMIS)
• Une infrastructure B de Gaia Data (ex: Infra XXX pôle THEIA)
• SSO Gaia Data

Pré-requis

• L'utilisateur est authentifié au SSO Gaia Data

Description

Ce use case présente l'utilisation de données protégées (i.e. requérant authentification auprès du SSO) issues d'une infrastructure A, dans une chaîne de traitement qui tourne dans une infrastructure B en mode asynchrone. Les infras A et B sont dans des pôles de Gaia Data (dans notre exemple DINAMIS et THEIA). On pourrait transposer cet exemple à d'autres infrastructures et à d'autres pôles, par exemple pour permettre de croiser des données météo avec des observations terrain. L'asynchronisme du traitement est l'aspect crucial de ce use-case.

• L'infra A diffuse des données. Elle nécessite que l'utilisateur soit authentifié auprès du SSO pour pouvoir accéder aux données.
• L'infra B héberge un service de traitement asynchrone, c'est à dire que les traitements sont poussés dans une file d'attente, mais leur exécution est différée. Elle nécessite que l'utilisateur soit authentifié auprès du SSO pour pouvoir soumettre un traitement.

Dans ce use-case, on considère un traitement qui tourne en différé sur l'infra B et qui a besoin de consommer des données protégées de l'infra A.

sequenceDiagram
    participant USER
    participant SSO
    participant Infra_A
    participant Infra_B
    USER->>SSO: Login
    SSO-->>USER: Login successful
    USER->>Infra_B: Submit(Process(https://Infra_A.theia.fr/data/xyz.tif))
    loop File d'attente...
        Infra_B->>Infra_B: Busy 
    end
    Note right of Infra_B: Entering job
    loop Le traitement démarre
        Infra_B->>Infra_A: HTTP GET https://Infra_A.theia.fr/data/xyz.tif
        Infra_A-->>Infra_B: Receive file xyz.tif
        Infra_B->>Infra_B: Processing xyz.tif 
    end
    Note right of Infra_B: Stockage du résultat et notification

cf notes: ce diagramme est volontairement simplifié et ne présente pas toutes les interactions nécessaires entre infra A/B et SSO, car peut être que plusieurs implémentations sont envisageables

Fins possibles?

Infra_A doit appliquer la même politique sur la requête venant de Infra_B, que si elle venait directement de USER. En effet USER est soumis aux mêmes contraintes de l'utilisation du service (licenses sur les données, autorisations, ...), qu'il passe en direct ou via une autre plateforme de Gaia data.

Points vitaux vis-à-vis de l'authentification

Problématique de l'asynchronisme.

• Durée entre le moment où l'utilisateur se connecte, et le moment où le traitement qu'il a soumis sort de la file d'attente: quelles implémentations pour garantir que les credentials de l'utilisateur passés n'aient pas expirés?

Use-cases associés

• #4
• #2

Notes

• Ce use case pourrait convenir aussi à des traitements automatiques pour de la production avec des données hétérogènes des différents pôles de Gaia data (avec USER = un compte de service)
• Article intéressant sur OAuth2 + queues https://nordicapis.com/how-to-handle-batch-processing-with-oauth-2-0/
• Implémentation possible avec token exchange (testé et fonctionne!) cf. exemple d'implémentation de token exchange ici