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
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