EXI EDC PSC 115

Document de conformité Pro Santé Connect
ans
Pro Santé Connect
Document de conformité
xxx
Chapitre 1 : Prérequis Maturité Technique

Cette section décrit la gestion des identifiants de corrélation tout au long de leur cycle de vie.

En tant que FS, je dois aussi m’assurer que ces identifiants de corrélation n’apparaissent pas auprès de l’utilisateur final.

EXI EDC PSC 115
Éditeur de Logiciel Utilisateur Éditeur de Logiciel Proxy e-santé
[[Il est attendu que le Fournisseur de Service décrive le processus de génération des identifiants, le processus de gestion des traces d’identifiants, le déroulement théorique de l’authentification et les types de contrôles de bac à sable applicables (avec des liens de test)
OU fasse référence à un extrait, clairement identifié, d’un document qu’il fournira.
]

Décrire le processus de génération des identifiants

Le Fournisseur de Service doit expliquer comment sont créés les identifiants techniques utilisés lors de l’authentification.

Selon le contexte, il peut s’agir par exemple de :

  • identifiants clients (Client ID)
  • secrets clients (Client Secret)
  • certificats
  • clés cryptographiques
  • comptes techniques.

Il convient notamment de préciser :

  • qui les génère
  • à quel moment
  • selon quelles règles (unicité, aléa, longueur, etc.)
  • comment ils sont transmis et protégés.

Décrire le processus de gestion des traces d’identifiants

Il faut expliquer comment les identifiants et leur utilisation sont tracés.

Cela comprend généralement :

  • les journaux d’authentification
  • les créations, modifications et suppressions d’identifiants
  • les utilisations des identifiants
  • les échecs d’authentification
  • les règles de conservation des journaux
  • les mesures empêchant la divulgation d’informations sensibles (par exemple, ne jamais enregistrer un mot de passe ou un secret en clair dans les logs).

L’objectif est d’assurer la traçabilité sans compromettre la sécurité.

Décrire le déroulement théorique de l’authentification

Le Fournisseur de Service doit présenter le fonctionnement de l’authentification, étape par étape.

Par exemple :

1- L’utilisateur accède au service.

2- Il est redirigé vers le fournisseur d’identité (PSC).

3- Il s’authentifie.

4- Le proxy renvoie un jeton d’authentification.

5- Le Fournisseur de Service vérifie le jeton.

6- Une session est créée.

7- L’utilisateur accède au service.

L’objectif est de décrire clairement les échanges entre les différents composants.

Exemple CIBA/Code Flow à personnaliser :

!theme aws-orange
actor "Utilisateur/Front web logiciel" as U
participant "Backend Logiciel utilisateur" as FS
participant "Proxy eSanté\n(Spring Boot)" as Proxy
participant "Pro Santé Connect\n(Serveur OIDC/CIBA)" as PSC
participant "Services de l'EDC" as EDC


== Authentification par CIBA ==
U -> FS : POST /connect (nationalId, binding_message,…)
FS -> Proxy : POST /oauth2/ciba (nationalId, binding_message, channel, clientId)
Proxy -> Proxy : Génération correlationId
Proxy -> PSC : POST /backchannel-authentication avec header X-Correlation-Id
PSC -> U : Notification via App Mobile (Smartphone) ou CPS Gestion (Carte CPS))
U -> PSC : Confirme l’authentification
PSC -> Proxy : Authentication Result
Proxy -> Proxy : Génération d'un Bearer token
Proxy --> FS : Bearer token <b>AVEC</b> header X-Correlation-Id
FS --> U : Bearer token <b>SANS</b> header X-Correlation-Id
alt Ou génération par le backend utilisateur d'un autre bearer, d'un cookie d'authentification ou autre ...
FS --> FS : Sauvegarde du Bearer dans la session et renvoi d'un autre identifiant de session
FS --> U : Identifiant session <b>SANS</b> header X-Correlation-Id
end

== Authentification par Code Flow ==
U -> Proxy : GET /oauth2/codeflow/{clientId}?redirectUri=
Proxy --> U : Redirection vers PSC (Authorization Code Flow)
U -> PSC : Authentification PSC
PSC -> U : Notification via App Mobile (Smartphone) ou CPS Gestion (Carte CPS))
U -> PSC : Confirme l’authentification
PSC --> U : Redirection avec Authorization Code
U -> Proxy : Suivi redirection
Proxy -> PSC : Récupération PSC tokens
PSC --> Proxy : tokens
Proxy -> Proxy : Génération d'un Bearer token
Proxy -> U : Redirection avec code
U -> Proxy : POST /oauth2/codeflow/token/{code}
Proxy --> U : Authorization Bearer


== Appel aux APIs protégées ==
U -> FS : Appel REST avec Authorization Bearer
FS -> Proxy : Appel Service EDC avec Authorization Bearer
Proxy -> Proxy : Vérification Access Token
alt Token exchange si absent ou expiré
Proxy -> EDC : Token exchange si nécessaire\n(avec le header X-Correlation-Id)
EDC -> Proxy : token
end
Proxy -> EDC : Appel Service avec token\n(et le header X-Correlation-Id)
EDC --> Proxy : Réponse
Proxy --> FS : Réponse\n(avec le header X-Correlation-Id)
FS --> U : Réponse

Décrire les contrôles de bac à sable (sandbox)

Le Fournisseur de Service doit indiquer quels tests peuvent être réalisés dans un environnement de préproduction (sandbox).

Par exemple :

  • authentification réussie
  • authentification échouée
  • utilisateur inconnu
  • certificat invalide
  • jeton expiré
  • révocation d’un certificat
  • contrôle des erreurs.

Il doit également fournir les informations permettant d’effectuer ces tests :

  • URL de l’environnement de test
  • documentation
  • comptes de test
  • éventuels identifiants techniques.