Ressources techniques pour FI tiers

Valeurs AMR : cadre actuel et règles d’évolution

Dans le cadre de la délégation, le FI local transmet à PSC des valeurs AMR (Authentication Methods References) qui caractérisent le niveau et la nature de l’authentification réalisée.

Valeurs AMR actuellement autorisées

Dans le cadre de la délégation de l’authentification, Pro Santé Connect supporte actuellement un ensemble de couples (ou ensembles) de valeurs AMR permettant de caractériser des scénarios d’authentification forte, multi-facteurs et résistants au phishing.

Les valeurs supportées reposent sur les briques suivantes :

• fido : authentification cryptographique de type FIDO (clé matérielle, passkey, etc.)

• rsa : carte à puce (CPS, carte professionnelle)

• pwd : mot de passe

• mfa : indicateur d’authentification multi-facteurs

Les combinaisons actuellement reconnues sont notamment les suivantes :

• fido, rsa, mfa
  Authentification par clé FIDO et carte à puce, avec validation par code porteur (PIN).
  → Authentification forte à deux facteurs (possession + connaissance).

• pwd, fido, mfa
  Authentification par mot de passe et clé FIDO.
  → Authentification forte à trois facteurs combinés (connaissance + possession + validation locale).

• pwd, fido, rsa, mfa
  Authentification par mot de passe, clé FIDO et carte à puce.
  → Authentification forte multi-facteurs combinant plusieurs mécanismes de possession et de connaissance.

• rsa, mfa
  Authentification par carte à puce avec code porteur (PIN).
  → Authentification forte à deux facteurs (connaissance + possession )

• fido, mfa
  Authentification par clé FIDO avec validation locale.
  → Authentification forte à deux facteurs (connaissance + possession )

Ces ensembles sont fournis à titre de référence et peuvent évoluer. La liste de référence publiée par l’ANS fait foi.

Valeurs AMR personnalisées et moyens d’identification éditeur

En complément des valeurs AMR actuellement supportées, un éditeur peut proposer des valeurs AMR personnalisées, sous réserve qu’elles respectent le cadre défini.

Ces valeurs personnalisées peuvent notamment correspondre à :

• un moyen d’identification développé par l’éditeur ;

• ou un mécanisme d’authentification spécifique, intégré à sa solution de gestion des identités.

Dans tous les cas, les conditions minimales suivantes doivent être respectées :

• conformité à la norme RFC 8176 pour la structuration et la sémantique des valeurs AMR ;

• capacité démontrée à caractériser une authentification forte à deux facteurs résistante au phishing.

Les valeurs AMR personnalisées font l’objet d’une analyse et d’une validation dans le cadre du processus de référencement, afin de garantir leur cohérence avec le niveau de sécurité attendu par Pro Santé Connect.

Définition attendue : “2FA résistante au phishing”

On entend par “2 facteurs résistante au phishing” une authentification qui :

• repose sur au moins deux facteurs (ex. possession + connaissance) ;
• et dont au moins un facteur inclut un mécanisme non rejouable et lié au service (ex. authentification cryptographique de type FIDO2 / passkeys), limitant les risques d’hameçonnage et d’interception.

Architecture d’intégration et impact sur le paramètre kc_idp_hint

Le paramètre kc_idp_hint permet à Pro Santé Connect d’identifier la configuration FI à utiliser pour rediriger l’utilisateur vers la mire d’authentification locale. La valeur dépend de l’architecture retenue :

Approche “multi-tenant” (mutualisée)

• Une URL de service unique est utilisée pour tous les établissements clients.
• Le kc_idp_hint est généralement commun à l’ensemble des établissements utilisant la solution.

Approche “mono-tenant” (spécifique par établissement)

• Chaque établissement dispose d’une configuration dédiée.
• Le kc_idp_hint est distinct pour chaque établissement.

Ces principes et la structuration attendue du kc_idp_hint sont détaillés dans la fiche de configuration FI tiers

Tests et contrôles : AMR, traçabilité, preuve de conformité

Les scénarios de tests associés à la délégation, incluant la vérification des claims AMR et des mécanismes de traçabilité, sont décrits dans le document de référence « Étapes et contrôles de la mise en œuvre de la délégation ».

Ces tests visent à vérifier :

• la cohérence entre le scénario d’authentification réellement mis en œuvre par le FI ;

• les valeurs AMR transmises à Pro Santé Connect ;

• la capacité du FI à démontrer le niveau de sécurité effectivement atteint.

Dans certains cas, l’intégralité des scénarios ne peut pas être reproduite de manière exhaustive côté Pro Santé Connect (notamment lorsque l’authentification repose sur des composants locaux ou des dispositifs matériels).

Dans ce contexte, le Fournisseur d’Identité est tenu de fournir des éléments de preuve permettant de confirmer la conformité du dispositif, tels que :

• des horodatages d’événements d’authentification ;

• des journaux techniques (logs) pertinents ;

• des extraits de configuration ou de paramétrage ;

• tout autre élément attestant du déroulement effectif du scénario revendiqué.

Cette approche permet de concilier exigence de contrôle, réalisme technique et responsabilité des acteurs.

Datapass : déposer une demande spécifique à la délégation

Pour mettre en œuvre la délégation, l’établissement doit déposer une demande Datapass dédiée à cet usage. Cette demande permet d’identifier clairement le périmètre “délégation FI tiers”, distinct des autres besoins PSC.

Choisir et utiliser le kc_idp_hint : deux modes d’expérience utilisateur

Mode 1 — Expérience transparente

Dans le mode dit « expérience transparente », l’établissement de santé met en œuvre une intégration permettant de transmettre automatiquement le paramètre kc_idp_hint lors de l’appel à l’endpoint d’autorisation Pro Santé Connect.

Ce mode présente plusieurs enjeux et bénéfices :

• l’utilisateur n’a aucune action supplémentaire à effectuer ;

• il est redirigé automatiquement vers la mire d’authentification de son établissement ;

• l’expérience est fluide, homogène et cohérente avec les usages quotidiens.

Pour parvenir à ce fonctionnement, plusieurs approches techniques peuvent être envisagées par la DSI, en fonction de l’architecture du SI :

• réécriture ou enrichissement des URLs de redirection vers Pro Santé Connect ;

• paramétrage du fournisseur d’identité local pour inclure systématiquement le kc_idp_hint ;

• utilisation de plugins ou de connecteurs au niveau du portail applicatif ou du middleware d’authentification ;

• intégration via un proxy ou une passerelle capable d’injecter dynamiquement le paramètre en fonction du contexte utilisateur.

Le choix de la méthode dépend du niveau de maturité IAM de l’établissement, de son outillage existant et de son organisation interne.
Ce mode est fortement recommandé car il permet de maximiser à la fois l’ergonomie utilisateur et la maîtrise du parcours d’authentification.

Mode 2 — Sélection manuelle sur la mire PSC

À défaut de transmission automatique, l’utilisateur doit sélectionner l’onglet Délégation sur la mire PSC, puis choisir dans la liste déroulante la valeur de kc_idp_hint communiquée par la DSI.

Dans les deux cas, le kc_idp_hint est la “clé” qui conditionne la redirection vers le bon FI et la bonne configuration.

La délégation de l’authentification repose sur plusieurs mécanismes temporels qu’il est important de distinguer.

Durée de vie de l’appairage
L’appairage entre un établissement et une solution FI local est actuellement défini avec une durée de validité de trois mois.
Cette valeur est susceptible d’évoluer. Elle résulte d’un compromis entre :

• la nécessité de limiter les appairages obsolètes ou non maîtrisés ;

• et la volonté de préserver une expérience utilisateur acceptable pour les établissements et les équipes techniques.

Durée de vie des sessions Pro Santé Connect
Indépendamment de l’appairage, une session Pro Santé Connect a une durée maximale de quatre heures.
Un utilisateur sera donc amené à se ré-authentifier auprès de Pro Santé Connect au plus tard quatre heures après sa première authentification, même si sa session locale est toujours active.

Cette séparation entre appairage, session locale et session PSC participe à un modèle de sé