Sécurisation de la couche transport API REST Pro Santé Connectée
1.2.0 - ci-build
This page is part of the Sécurisation de la couche transport API REST (v1.2.0: Release) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
Une API REST est une interface de programmation qui suit les principes de l’architecture REST.
Elle permet aux clients (des applications web ou mobiles) de communiquer avec un serveur en utilisant des requêtes HTTP. Les ressources cibles sont identifiées par des URLs.
Dans une API REST, les opérations CRUD (Create, Read, Update, Delete) sont implémentées via les méthodes dans une requête : POST, GET, PUT, et DELETE respectivement.
Les réponses à ces requêtes sont retournées en format JSON
.
Le protocole HTTP1.1 encapsulé dans une connexion sécurisée TLS doit être utilisé.
Pro Santé Connect est le fournisseur d’identité de la santé pour les acteurs de santé professionnels en France. Il s’agit d’un service basé sur le protocole standard OpenID Connect
.
Il permet aux professionnels de santé de s’identifier de manière simple, sécurisée et unifiée.
Ils se connectent aux services numériques en santé, en passant de l’un à l’autre de manière fluide.
Une application Pro Santé Connectée est une application web ou client lourd qui permet aux professionnels (PS) de s’authentifier à l’aide d’un MIE PSC compatible.
Ces applications sont généralement utilisées par des établissements de santé/e-santé pour la gestion de leurs dossiers médicaux.
Pour accéder au service d’authentification de PSC permettant d’accéder à des API Pro Santé connectées, deux cinématiques sont disponibles :
flux authorization code
[4]Client Initiated Backchannel Authentication (CIBA)
[5]Description du protocole OpenID Connect
OpenID Connect (OIDC)
est un protocole d’authentification qui s’appuie sur OAuth 2.0
pour fournir une identification sécurisée et basée sur des jetons pour les applications Web et mobiles.
OIDC
fournit une couche d’authentification supplémentaire au-dessus d’OAuth 2.0
, qui permet aux clients d’obtenir des informations d’identification et de profil sur les utilisateurs en utilisant des ID tokens
.
Ce protocole utilise des jetons JSON Web Tokens (JWT)
pour échanger des informations d’identification entre l’application cliente, le fournisseur d’identité et le service/système cible.
La documentation technique Pro Santé Connecté [4] fournit des détails sur le fonctionnement du protocole OIDC
au sein de PSC.
OAuth 2.0
est un protocole standard d’autorisation qui permet à une application tierce d’accéder à des ressources protégées. Le protocole OAuth 2.0
définit des étapes à suivre pour obtenir et utiliser un jeton d’accès (access_token
).
Ce jeton est délivré par le serveur d’autorisation et permet d’accéder aux ressources d’une application protégée.
Les services de e-santé utilisent ce standard OAuth 2.0
pour la gestion des autorisations et des accès.
OAuth 2.0
est un protocole d’autorisation qui permet à une application (le client) de se connecter aux ressources protégées sur service cible en utilisant un access_token émis par un serveur d’autorisation.
Ce dernier est responsable du contrôle d’accès du client, de l’émission et de la gestion de ces jetons d’accès et de la vérification du jeton d’accès.
D’autre part, le serveur d’autorisation va effectuer le contrôle d’accès sur les scopes de l’application appelante à l’aide de l’identifiant du client (Client_ID_AS
) et des scopes
associés dans la requête.
À l’issue du contrôle d’accès, le serveur d’autorisation va délivrer un jeton d’accès (access_token
) permettant d’accéder aux ressources du système cible.
Le serveur d’autorisation est un composant essentiel du flux OAuth 2.0
qui permet de garantir la sécurité et la confidentialité des données de l’utilisateur et doit être implémenté côté service/système cible.
La règle générale d’autorisation portera toujours sur une structure et son service. Une structure est soit une structure de santé ou une structure autorisée (proxy éditeur).
scope
dans le protocole OAuth 2.0
Dans le protocole OAuth 2.0
, les scopes
sont utilisés par le client pour demander un accès limité aux données du propriétaire de la ressource.
Les scopes sont utilisés pour définir les autorisations que le client demande auprès du service cible propriétaire de la ressource. Ils décrivent les actions que l’application sera autorisée à effectuer ou le périmètre de données sur lequel l’application sera autorisée d’agir.
Afin d’illustrer l’usage du scope
au sein d’un processus fonctionnel, on peut prendre l’exemple simplifié d’un utilisateur qui souhaite accéder aux ressources protégées d’un service de e-santé.
Dans le cas des API Pro Santé Connectées, le Professionnel de Santé (PS) est redirigé vers PRO Santé CONNECT par le fournisseur de service.
Une fois le PS authentifié sur PSC, celui-ci envoie les tokens PSC au fournisseur de services.
L’authentification du fournisseur de services auprès du serveur d’autorisation se fait selon la RFC 7235 [11] c’est-à-dire avec un Client_ID_AS
dans le header de sa requête.
Authentification Basic
qui encode les credentials en base 64.Le fournisseur de service envoie une requête auprès du serveur d’autorisation qui contient comme paramètres, un subject_token
(dans le cas des API ProSantéConnectées : subject_token
= Access Token PSC
), un certificat de structure et des scopes métier
.
Une fois le contrôle d’accès est réalisé par le serveur d’autorisation, le PS peut accéder au service de e-santé.
La sécurité liée au stockage de l’access token et à sa conservation est définie par l’ANSSI dans le document Recommandations pour la sécurisation de la mise en œuvre du protocole OpenID Connect
dans la section 3.4 Recommandation R23 à R26. [6]
Recommandation :
Une fois envoyé, les attributs de validité de l’access_token pourront être conservés par le système cible, notamment au sein d’un cache au niveau du serveur d’autorisation.
Afin de résoudre le problème de l’éventuelle révocation de l’access_token
, la recommandation est de définir la durée de validité de l’access_token
, émis par le serveur d’autorisation, entre 1h et 4h.
Il est également fortement recommandé de vérifier la validité de l’access_token
toutes les demi-heures en utilisant le service d’introspection du serveur d’autorisation.
Si l’access_token
est un jeton autoporteur JWS
l’introspection n’est pas nécessaire, mais si c’est un jeton JWT
opaque, elle l’est.
access token
Les données de l’access token peuvent être accessibles soit dans un jeton JWT
signé (JWS
) par le serveur d’autorisation, soit via un appel à un service d’introspection.
Les paramètres de l’access token
sont définis par les champs suivants :
Champs |
Description |
iss |
Identifiant de l'émetteur du jeton |
sub |
Identifiant de l'utilisateur pour lequel le jeton a été émis |
aud |
Identifiant ou liste d'identifiants des services cibles qui peuvent être accessibles avec ce jeton |
nonce |
Chaîne de caractères aléatoires unique qui peut être utilisée pour identifier les échanges entre le client et le serveur |
exp |
Heure d'expiration du jeton, après laquelle il ne sera plus valide. Il est de la responsabilité des services de déterminer la durée de vie de l’access token (une durée de vie pas trop courte est à privilégier) |
iat |
Heure à laquelle le jeton a été émis |
scope |
Définit le type et le périmètre des ressources octroyées par le serveur d’autorisation. Sur cette base, le serveur d'autorisation authentifie l'utilisateur et recueille son consentement pour la transmission des ressources |
Exemple de contenu d’un access_token
dont la durée de vie est d’une heure :
{
"iss": "https://server.example.com",
"sub": "identifiant_national",
"aud": [Ressource A, Ressource B],
"nonce": "n-0S6_WzA2Mj",
"exp": 1626921770,
"iat": 1311280970,
"scope": “scope 2 scope 3”,
}
OAuth 2.0
Dans le cadre d’un workflow OAuth 2.0
, l’utilisation du mTLS permet :
Ci-dessous une illustration de l’utilisation du mTLS avec OAuth 2.0
.
Le détail des flux OAUTH 2.0
+ mTLS est défini dans :
Le protocole TLS est assuré sur la couche transport.
Le certificat client utilisé dans le mTLS peut être transmis au serveur d’autorisation.
Le protocole OAUTH2
est réalisé sur la couche applicative et permet de faire le contrôle du certificat client et de générer un access_token
.
Nota Bene :
Dans le cas des APIs Pro Santé Connectées, l’authentification sur le serveur d’autorisation du service cible n’utilise pas la méthode Authentification Basic
mais une authentification mTLS.
Pour plus de détail sur le mode d’authentification sur les APIs Pro Santé Connectées, rendez-vous sur les pages : Appel d’une API Pro Santé Connectée depuis une application web et Appel d’une API Pro Santé Connectée depuis une application client lourd ou mobile
Rappel sur les certificats émis une IGC Santé :
Un certificat de personne morale (également appelé certificat d’organisation) est un document électronique qui identifie une personne morale, telle qu’une entreprise, une organisation gouvernementale ou une association, auprès d’une autorité de certification (AC).
Il sert à garantir l’authenticité et l’intégrité des communications électroniques émises par la personne morale, en fournissant une signature électronique associée à son identité.
Un certificat serveur SSL/TLS est un document électronique qui identifie un serveur web auprès d’une autorité de certification (AC).
Il est utilisé pour garantir l’authenticité et la confidentialité des communications entre un navigateur web et un serveur, en chiffrant les données échangées.
Les certificats serveur sont utilisés pour sécuriser les connexions HTTPS, qui sont devenues la norme pour les sites web.
Recommandation :
Pour plus de précisions sur le contenu du certificat, voir le document [7]
Pour plus de précisions sur le contenu du struct_IdNat voir la section 5.5 [8]
Si certaines structures souhaitent indiquer le FINESS géographique, elles le pourront, mais la recommandation reste le FINESS juridique.