Objectifs du service
Introduction
Certaines applications externes ont besoin de réaliser des traitements sur la donnée du PDA.
Ce service permet donc d’exposer une API à destination d’applications extérieures au PDA et de centraliser les comptes de services associés à ces différentes applications externes. On peut voir ce service comme un proxy d’entrée vers les différents services du PDA (referentiel-tiers, connecteur-gestions-financieres, etc…). Les objectifs de ce service sont les suivants :
- exposer une API permettant à des applications externes d’interragir avec les services privés du PDA (consommation d’API ou requêtage) de manière sécurisé (authentification)
- centraliser les comptes de services externes + gérer le périmètre d’action de ces comptes via un group role mapping.
Création d’un compte de service
Chaque compte de service appartient à un groupe et chaque groupe possède un ou plusieurs roles externes. Les roles externes n’existent que dans ce service. Un mapping entre les groupes et les roles externes est réalisé au sein du pda-semi-public-api. Le service se charge ensuite de traduire ces roles externes en roles internes, compréhensible et utilisable sur les services privés du PDA.
Les roles externes permettent de définir le périmètre d’action du groupe. Ces roles sont définis directement dans le service pda-semi-public-api.
Les comptes de services externes sont centralisés dans ce service.
Consommation de service
A noter que pour réaliser certains traitements, l’application externe n’a pas à connaitre toutes les informations (informations privées ou informations relative au fonctionnement interne du PDA). Dans l’exemple du schéma ci-dessus, MF-ASP (l’application externe) souhaite mettre à jour un dossier financier. Pour celà, il a seulement besoin de fournir la référence de la GF (« 12345 ») ainsi que le nouveau statut du dossier externe (« CREE »). C’est le service pda-semi-public-api qui va ajouter les informations privées, nécéssaire au bon fonctionnement du traitement (dans l’exemple du schéma, on ajoute typeGestionsFinanciere, codeCollectivite, codeBudget, typeMouvement).
Après la réception d’une requête sur son API, le service pda-semi-public-api va valider ou non la requête (en fonction du basic-auth de la requête). Si l’étape d’authentification est validé (le compte de service est référencé dans le service, le mot de passe est correct et a le rôle adéquat pour cette opération), alors l’API semi publique va requêter (en tant que adminTenant) account-management pour récupérer un jeton JWT PDA.
C’est avec ce JWT que le service pda-semi-public-api va pouvoir orchestrer les différentes actions à mener pour réaliser le traitement demandé par l’application externe. Sur le schéma, cela se traduit par une requête vers le connecteur-gestions-financieres.
Une fois le traitement réalisé, le service pda-semi-public-api va récupérer les réponses internes des différents services impactés par ce traitements et va intelligemment les transformer pour transmettre une réponse finale au client :
- si c’est OK, une réponse ne renvoyant que les données publiques est envoyé
- si c’est NOK, une réponse donnant les moyens à l’application externe de savoir ce qu’il s’est passé, d’ou vient le problème (erreur métier/erreur technique)
Requêtage de services
Sécurisation du nombre d’appel entrants sur une route d’API
Il est possible de limiter le nombre d’appel sur une route d’API semi-publique en utilisant un « rate-limiting ». Ce paramétrage peut se faire via une demande à un administrateur technique de la plateforme.