I.AM et I.AM Connect (Identity & Access Management)

I.AM (Identity & Access Management) est le service eHealth intégré d'identification, d'authentification et d'autorisation des acteurs de soins qui demandent l'accès à des services de la Plate-forme eHealth et de ses partenaires^[1]. Il intègre la gestion des accès, des utilisateurs et de l'accès aux données, et distingue quatre contextes techniques : applications web, services web SOAP, services web REST et accès aux données (Data Access)^[1]. L'utilisateur choisit un profil sur la base de sa qualité telle qu'elle est consignée dans CoBRHA^[2].

I.AM fait en sorte que chaque application qui appelle des services eHealth ou des services partenaires établisse d'une manière commune qui est l'utilisateur ou le système et en quelle qualité il agit^[1][2]. Le certificat identifie le système (logiciel/organisation), l'eID ou un jeton identifie l'utilisateur individuel^[3].

Pour les applications web, la spécification IDP (version 1.4, 14/10/2025) distingue trois niveaux de sécurité : itsme, eID et MyGov sont de niveau High, TOTP Substantial et nom d'utilisateur/mot de passe Low^[4]. L'IDP s'appuie sur le service d'authentification fédéral BOSA FAS^[4] ; en production, la plupart des applications redirigent automatiquement l'utilisateur vers le FAS^[4]. La spécification annonce que le « Belgian citizen token » (carte comportant 24 codes personnels) disparaîtra prochainement des méthodes d'authentification (spécification du 14/10/2025 ; le moment effectif n'a pas été trouvé)^[4]. Après l'authentification, I.AM applique les règles d'accès de l'application^[5].

Statut : production, comme service de base de la plate-forme eHealth^[2]. Les composants :

• IDP par rapport à Connect : pour les applications web classiques, la plate-forme eHealth recommande I.AM IDP ; les applications mobiles/natives et REST passent par I.AM Connect^[1].
• STS : le consommateur du service s'authentifie auprès du STS avec un certificat eHealth ou une eID, et le STS délivre un jeton SAML permettant d'appeler plusieurs services web pendant sa période de validité^[6]. Selon le cookbook STS WS Trust (version 1.2), la plate-forme eHealth renvoie au consommateur du service web une assertion SAML signée dans un RequestSecurityTokenResponse (RSTR)^[8]. Selon la page web « Beveiliging van webservices », le consommateur demande à cette occasion un jeton SAML 1.1 et signe l'appel SOAP selon la policy X.509 SHA256^[6]. Le même cookbook accepte pour l'élément obligatoire TokenType aussi bien « SAML1 response » que « SAML2 response »^[8] et contient un exemple de réponse pour SAML2^[8] ; cela montre une prise en charge, non un passage obligatoire.
• I.AM Connect repose sur OIDC ; pour les services REST, l'authentification et l'autorisation des clients s'effectuent via OIDC et non via SAML^[1][7].
• I.AM AA permet aux partenaires de consulter les sources authentiques eHealth, dont CoBRHA et les mandats, indépendamment de l'accès aux applications^[1][2]. La consultation des relations thérapeutiques passe également par I.AM AA ; ces services devaient être réécrits techniquement fin 2025, avec une mise en service prévue le 2 décembre 2025^[9] ; la mise en service effective n'a pas été confirmée.

Applications : l'environnement FHIR de Vitalink (en production depuis le 22/03/2024) utilise I.AM Connect^[10], de même que Vaccinnet 2.0^[11]. Selon le cookbook FHIR de Recip-e, l'API FHIR d'UHMEP exige, pour les clients du realm Healthcare, le flux IAM token exchange, de sorte que les providers techniques n'obtiennent pas de droits de pseudonymisation^[12] (voir UHMEP et la prescription de renvoi électronique (eReferral)) ; pour les clients M2M, cela n'a pas été vérifié. Les variantes REST de l'eHealthBox et de l'Addressbook demandent un onboarding I.AM Connect distinct^[13] (voir eHealthBox).

Interfaces techniques

• Clients et realms : lors de l'onboarding, on choisit entre un enregistrement de client « Healthcare » (prestataire de soins ou application) et « M2M » (organisation)^[13]. Selon la spécification technique « IAM Mobile integration » (version 1.13), le flux client credentials n'est disponible que pour des clients d'organisation ou d'institution et ne prend pas en charge l'authentification d'un utilisateur final^[14] ; une application qui agit au nom d'un prestataire de soins individuel a donc besoin d'un autre flux (déduction). Un client-ID M2M d'une institution de soins a le format nihdi-<type>-XXXXXXXX avec le numéro INAMI de l'institution^[13]. Dans l'API FHIR de Recip-e, les pharmacies hospitalières (Le pharmacien hospitalier et le schéma de médication partagé) utilisent un client M2M propre et ne peuvent pas réutiliser le client de l'hôpital^[12].
• Choix d'architecture : la plate-forme eHealth propose SOAP pour les applications sur un seul appareil et REST pour les applications sur plusieurs appareils ; pour les nouveaux projets mobiles, REST est privilégié^[15].
• Sécurisation des messages : les données médicales doivent être sécurisées au moins au niveau du message, pas uniquement au niveau du transport^[15] ; un chiffrement end-to-end complet n'est pas toujours exigé, mais la communication doit au moins être sécurisée point-to-point^[15].

État et feuille de route

• Ancien endpoint STS retiré : le service Saml11TokenService (endpoint iamsaml11tokenservice) n'est plus utilisé depuis octobre 2023 ; les connecteurs doivent utiliser l'endpoint SecurityTokenService, faute de quoi survient l'erreur « SOA-03005 WSDL compliance failure »^[16].
• Renouvellement des clés 2026 : le 7 juillet 2026, la plate-forme eHealth a annoncé un renouvellement obligatoire des certificats/clés pour les intégrations SAML existantes (IDP/STS/AA) et pour la validation JWT dans I.AM Connect ; ceux qui gèrent manuellement des métadonnées ou des truststores devaient adapter cela avant le 22/07/2026^[17]. Ce message porte le titre « ERRATUM » et met ses corrections en évidence en jaune^[17] ; il mentionne pour les deux types de gestion l'échéance « avant le 22/07/2026 »^[17]. Un message du 11/06/2026 portant le même titre mentionnait d'autres dates : métadonnées « à partir du 26/05/2026 pour ACC et 24/06 PRD et avant le 6/10/2026 »^[18] et truststore « à partir du 29/07/2026 et avant le 6/10/2026 »^[18]. Pour la JWT signing key, des dates distinctes s'appliquaient : acceptation nouvelle clé 07/07/2026 et retrait de l'ancienne 04/08/2026, production nouvelle clé 28/07/2026 et retrait de l'ancienne 26/08/2026^[17].
• Nouvelle version de l'IDP : le 28/07/2026, la plate-forme eHealth a annoncé la migration de son IAM IDP vers une nouvelle version en acceptation, avec des modifications du look-and-feel^[19]. Les partenaires sont invités à tester (au moins le login, le choix du profil, le contenu des access tokens et le logout)^[19] ; aucune modification n'est attendue chez les intégrateurs, la planification de la production n'est pas encore fixée^[19]. Le message s'adresse aux clients I.AM Connect ; les intégrateurs de l'eHealth IAM IDP reçoivent une communication distincte^[19].
• Nouveau certificat TLS (annonce) : dans un message du 18/08/2026 adressé à tous les utilisateurs de services du domaine *.ehealth.fgov.be, la plate-forme eHealth a demandé de tester avec un nouveau certificat TLS en acceptation à partir du 02/09/2026 ; le certificat serait actif en production à partir du 13/10/2026^[20]. Le message demande d'installer aussi bien la Root CA HARICA 2015 que HARICA 2021^[20]. Qui utilise les métadonnées TSL en ligne mentionnées dans le message pour valider la chaîne et la récupérer périodiquement n'a rien à faire^[20].
• SAML v2 (planification) : selon une présentation publiée publiquement destinée au personnel de la plate-forme eHealth (30 janvier 2026), Recip-e doit passer de SAML v1 à SAML v2, parce que la plate-forme l'exige en 2026 pour toutes les applications qui utilisent des services de base^[21].

• Condition technique : chaque connexion system-to-system avec les services de base eHealth exige un certificat eHealth^[3]. L'accès à certains services REST requiert en outre une intégration I.AM Connect^[2] ; pour les variantes REST de l'eHealthBox et de l'Addressbook, un onboarding I.AM Connect distinct est requis^[13]. Vitalink FHIR s'appuie également sur I.AM Connect^[10] ; pour les clients du realm Healthcare, l'API FHIR d'UHMEP exige le flux IAM token exchange^[12].
• Risque opérationnel : les renouvellements de clés et de certificats ont des dates strictes^[17]. Selon l'annonce, le nouveau certificat TLS pour *.ehealth.fgov.be devient actif en production à partir du 13/10/2026 ; un système qui ne fait pas confiance aux roots HARICA doit les installer ou utiliser les métadonnées TSL en ligne^[20]. Qui gère manuellement des truststores doit les mettre à jour à temps ; la plate-forme eHealth diffuse ses certificats de confiance selon la spécification ETSI pour les Trusted Lists, de sorte que cela peut être automatisé^[3].
• Recommandation (propre) : tenez un registre de tous les clients I.AM (Healthcare/M2M), des couplages STS et des truststores par application, avec un responsable par date de renouvellement.

Conditions de mise en œuvre et limites

Voir Certificats eHealth et chiffrement (ETEE) pour les certificats et Connecteurs eHealth (eHealth platform services connectors) pour les bibliothèques qui gèrent l'authentification STS et le chiffrement. Dans l'environnement d'acceptation, outre un certificat d'acceptation, le connecteur est également nécessaire^[22]. L'aperçu par service cible se trouve sur Intégration technique avec l'infrastructure eHealth.

• Version SAML : la présentation au personnel de janvier 2026 parle d'un passage obligatoire de SAML v1 à v2 en 2026^[21], alors que la page web « Beveiliging van webservices » décrit encore la demande d'un jeton SAML 1.1^[6], que l'ancien endpoint Saml11TokenService est retiré depuis octobre 2023^[16], et que la communication officielle de juillet 2026 porte sur le renouvellement des clés, non sur une version de protocole^[17]. Le cookbook STS 1.2 et la spécification IDP 1.4 prennent en charge, outre SAML 1.1, également SAML 2.0^[8][4] ; aucune date d'obligation officielle n'a été trouvée. Ce qui devient précisément obligatoire, et quand, n'est pas univoque.
• Échéances du renouvellement des clés : l'erratum du 07/07/2026 mentionne « avant le 22/07/2026 »^[17], le message du 11/06/2026 parlait de « avant le 6/10/2026 »^[18]. L'erratum porte le même titre que le message du 11/06/2026 et donne d'autres échéances (interprétation : l'erratum remplace ce message) ; quels passages ont été corrigés ne ressort pas du texte, car la mise en évidence en jaune n'est pas déductible^[17].
• Aucun plan de migration publié de SOAP/SAML vers OIDC n'a été trouvé (lacune).