Introduction à la notion de fournisseur de données

Au sens OpenID un fournisseur de données (FD)  correspond à un serveur de ressources (RS). 

Le fournisseur de données se distingue du fournisseur de service (FS) par le fait qu'il ne prend  pas en charge la cinématique d'authentification. En effet, il ne retourne les informations demandées uniquement sur présentation d'un access token valide émis par Pro Santé Connect. 

Un FD offre, aux FS,  un service spécifique d'enrichissement de la donnée issue du UserInfo. La communication entre un FS et un FD se base sur la norme Oauth.

Le FS va envoyer une demande au FD accompagnée de l'access token du demandeur qu'il aura authentifié. 

  • Le FD va vérifier la validité de l'access token envoyé par le FS par introspection et récupérer l'identité du demandeur 
  • Le FD va utiliser l'access token envoyé par le FS pour interroger le UserInfo si nécessaire dans la limite des scopes contenus dans l'AT obtenus par le FS.


 

Diagramme de flux

Devenir un fournisseur de données

Comme les FS,  le FD doit s'authentifier auprès de Pro Santé Connect pour avoir la capacité de vérifier la validité d'un access token. Pour cela vous devez créer vos accès auprès de Pro Santé Connect en faisant une demande de création de nouveau service depuis le menu "Gérez votre service

 

Les exigences de Pro Santé Connect

Contrairement à un FS le FD n'expose pas d'interface à l'utilisateur final.

Le FD n'étant pas exposé aux utilisateurs seule une partie des exigences du référentiel de Pro Santé Connect s'applique à son fonctionnement. En effet,  il n'est pas nécessaire pour lui de répondre à certains critères comme la charte graphique, la nécessité de rafraîchir une session, la déconnexion, etc... 

Un FS qui, par ailleurs, exposerait aussi son service sous forme de FD devra appliquer l'ensemble des exigences de Pro  Santé Connect.


L'ensemble des exigences s'appliquant aux FD et aux FS se trouvent sur la page suivante : Exigences liées aux FD

Détail des flux

Interrogation du FD 

Contexte : Le FS envoie un access token au fournisseur de données. Les détails de la communication entre le FS et le FD sont à définir entre les 2 protagonistes, PSC n'intervenant pas à ce niveau. 
 

  • Origine : FS
  • Cible : Fournisseur de données

Méthode : POST

Requête :

Paramètres de query
Paramètre Obligatoire Valeur
access token Oui 'access token'

Appel du FD au UserInfo

Contexte : Le fournisseur de données utilise l'access token valide, en provenance du FS,  pour récupérer le UserInfo. Cet appel est optionnel et dépend entièrement du FD et du service qu'il rend. 

  • Origine : FD
  • Cible : Endpoint UserInfo de PSC

La demande

  • Méthode d’appel : GET

 

Paramètre Header HTTP  Obligatoire Valeur
Authorization Oui l'access_token émis par Pro Santé Connect

Exemple d'appel au UserInfo: 

GET /userinfo HTTP/1.1
     Host: PSC.UserInfo.endpoint
     Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5c
  

La réponse de Pro santé Connect  au FD 

Le serveur renvoie les éléments contenus dans le UserInfo  et le contenu de la réponse dépend des scopes contenus dans l'access token reçus de la part du FS. Les scopes sont détaillés sur cette page

En cas d'access token invalide l'erreur suivante est renvoyée : 

{
    "error": "invalid_token",
    "error_description": "Token verification failed"
}

La communication retour entre le FD et le FS doit être définie entre les 2 protagonistes. 

Validation de l'access token par le fournisseur de données

Contexte : Le fournisseur de données valide par introspection l'access token reçu de la part du FS

  • Origine : FD
  • Cible : Endpoint d'introspection de PSC
  • Authentification : Le FD doit présenter son couple d'identifiants ou son certificat TLS

La demande

  • Méthode d’appel : POST
  • Body Content-type : application/x-www-form-urlencoded
Paramètre Obligatoire Valeur
token Oui l'access_token émis par PRO Santé Connect et reçu par le FS qui a authentifié l'utilisateur 
token_type_hint Oui 'access_token'

Exemple pour un appel avec une authentification avec un client ID et un client secret : 

POST /introspect HTTP/1.1
     Host: PSC.introspection.endpoint
     Accept: application/json
     Content-Type: application/x-www-form-urlencoded
     Authorization: Basic eyJhbGciOiJSUzI1NiIsInR5c

     token=mF_9.B5f-4.1JqM

La réponse de Pro santé Connect 

Le serveur renvoie les éléments suivants :

Paramètre Obligatoire Valeur
{Access_Token} Oui le contenu de l'access token est renvoyé dans la réponse
Active Oui

Booléen (True/false) qui indique si le jeton présenté est toujours actif ou non. 

SubjectNameID Oui Identifiant National du Professionnel de Santé

En cas d'access token invalide l'erreur suivante est renvoyée : 

{
    "active": false
}

Cette page vous a-t-elle été utile ?

Les informations recueillies dans le questionnaire sont enregistrées dans un fichier informatisé par l'ANS afin d’optimiser le site et satisfaire à vos attentes.

Les informations enregistrées sont destinées à l’usage de l’ANS et ne sont rendues accessibles qu’à ses services, personnels, prestataires externes ou partenaires habilités à en prendre connaissance.

Dans le respect de la réglementation applicable en matière de protection des données personnelles, vous disposez notamment d’un droit d’accès, de rectification et d’effacement de vos données.
Vous pouvez exercer ces droits en contactant le délégué à la protection des données de l’ANS, dans les conditions décrites sur la page dédiée Politique de protection des données personnelles du site de l’ANS.