Présentation rapide de Pro Santé Connect
Pro Santé Connect a pour objectifs de libérer les fournisseurs de service des contraintes techniques de l’authentification en fournissant un service d’authentification à l’état de l’art, conforme aux standards internationaux. Le service supporte différents dispositifs d’authentification afin de s’adapter aux différentes modalités métier des utilisateurs mais aussi afin de permettre l’évolution des dispositifs d’authentification sans impact sur les fournisseurs de service.
Pro Santé Connect est un service d’authentification délégué au sens du référentiel d’authentification de la PGSSI-S.
Pro Santé Connect regroupe un Fournisseur d’Identité (Pro Santé Connect) et un système d’authentification sur smartphone (e-CPS). Il libère les services utilisateurs des contraintes de l’authentification et de sa maintenance sécuritaire tout en garantissant à la fois la conformité réglementaire de celle-ci (PGSSI-S) et au volet transport pour les applications mobiles du CI-SIS.
Pro Santé Connect met en œuvre une technologie identique à celle de FranceConnect tout en propageant les identifiants et les professions / rôles / situations d’exercice des référentiels sectoriels. Pro Santé Connect est un fournisseur d’identité (FI) selon la norme OpenID Connect (OIDC), surcouche du protocole OAuth2.0.
Pour plus de détails, vous pouvez consulter la présentation générale de Pro Santé Connect, ainsi que la documentation technique.
Présentation du CIBA
CIBA, qu’est-ce que c’est ?
Le Client Initiated Backchannel Authentication Flow (Flux CIBA) est un flux nouveau dans le standard OpenID.
La spécification CIBA est approuvée depuis mars 2020. Elle rejoint ainsi le core Open ID.
Le flux CIBA prévoit que l’appareil de consommation (l’appareil sur lequel il consomme la ressource qui nécessite qu’il s’authentifie) et l’appareil d’authentification (l’appareil sur lequel il effectue son authentification) puissent être deux appareils différents.
Par exemple, un utilisateur peut utiliser une application client lourd depuis son ordinateur de bureau (appareil de consommation) et s’authentifier depuis son téléphone portable (appareil d’authentification).
La spécification CIBA venant tout juste d’être adoptée, les travaux de développements sont en cours. Soucieux de proposer dans les meilleurs délais la solution CIBA à ses partenaires, et de participer à l’effort de développement nécessaire, l’ANS a rejoint la communauté Open Source en charge de ces travaux.
Introduction à CIBA
Pro Santé Connect fonctionne conformément au standard OpenID qui définit des règles pour l’authentification en flux de redirection, donc dans un contexte où il y a un navigateur qui se charge de ces redirections.
Pro Santé Connect doit continuer sa trajectoire vers un Fédérateur de Fournisseurs d’Identité Sectoriels permettant de s’authentifier sur tout type de client. Un Fournisseur de service est :
| Un service en ligne | Authentification en flux de redirection / CIBA | PRO Santé Connect répond déjà à ce type de Fournisseur de service |
|---|---|---|
| Un logiciel type client lourd | CIBA | Un Client Lourd est un logiciel dont la majorité du fonctionnel est installé localement sur l’ordinateur d’un utilisateur. Le traitement des données se fait au niveau de la machine de l’utilisateur. |
| Une application mobile | CIBA | Un logiciel dont la majorité du fonctionnel est installé localement sur l’appareil d’un utilisateur. Le traitement des données se fait au niveau de la machine de l’utilisateur. |
| Un Web SSO | Authentification en flux de redirection / CIBA | un Web SSO est une interface d’authentification identification sans fonctionnel au même titre que PRO Santé Connect et la succession de deux mires de connexion est ergonomiquement laborieux. |
Afin de pouvoir répondre aux cas métiers où le flux de redirection n’est pas possible, Pro Santé Connect se doit de proposer une interface OpenID CIBA aux fournisseurs de service.
La communauté de travail CIBA
La communauté de travail CIBA est organisée autour d'un github. Elle regroupe des acteurs d’horizons variés : différents secteurs, différents pays, etc.
L’ANS est un des participants à cette communauté. Les membres communiquent majoritairement grâce à une mailing list gmail.
Des réunions bi-mensuelles sont organisées afin de discuter de l’avancement du projet, des tickets en cours, et autres sujets concernant la communauté.
CIBA Pro Santé Connect
Introduction de Pro Santé Connect à CIBA
Nous allons tout d’abord réaliser un POC CIBA afin de valider son fonctionnement, mais aussi l’architecture nécessaire à une implémentation sur le bac à sable puis en production.
La communauté fournit une implémentation minimale de CIBA sur laquelle s’appuyer. Il s’agit pour nous de l’utiliser dans notre POC en l’adaptant à notre contexte afin qu’il réponde aux besoins des industriels.
Nous allons implémenter dans notre POC :
- Un "Consumer Device (CD)" : application type client lourd ;
- Un "Decoupled Auth Server" : qui contactera l'application e-CPS de l'utilisateur pour recueillir son consentement.
Implémentation à date
- Le "Consumer Device (CD)" une application type client lourd
Il n’existe actuellement pas de librairie java permettant d’implémenter un client CIBA. Pour réaliser cette application, nous avons donc dû implémenter l'appel http de l'autorisation et le polling de l'access-token avec un client http, ainsi que les règles d'intervalle d'appel entre chaque polling et la gestion des "pending" et "slow_down".
Cette solution est acceptable pour un POC, mais ne suffira pas au moment de passer à l’étape supérieure (implémentation dans le wallet), car elle n’est pas suffisamment sécurisée et fiable. Ainsi, nous pourrons contribuer sur ce point une fois que nous aurons de notre côté une implémentation propre et fonctionnelle : cela permettra au reste de la communauté de bénéficier de nos travaux sur ce sujet.
Reste à faire
Après un premier niveau de POC réussi, nous avons réalisé un deuxième niveau de POC qui est une première version de la solution qui sera déployée dans le Bac à Sable.
Maintenant que le flux découplé peut contacter l'application e-cps (elle est donc le "SPI" : Service Provider Interface), nous allons implémenter ce POC dans un environnement Bac à Sable. Nous travaillons donc sur l'architecture cible.