Fiche de concept · Plateforme ou service
Affirmations : I.AM et I.AM Connect (Identity & Access Management)
- Plateforme ou service
- en production
- Belgique (fédéral/interfédéral)
- Identité, accès et audit
- Architecture et infrastructure
Identifiant Atlas i-am-connect · 65 affirmations · 29 sources · Dernière vérification08-10-2026
· Version 2026.11.12-3
I.AM est le service de base par lequel les applications eHealth identifient, authentifient et autorisent les acteurs de soins et les systèmes. La famille utilise l'IDP pour les applications web classiques, le STS pour les services web SOAP, I.AM Connect pour le REST et les applications mobiles, et l'Attribute Authority pour les attributs provenant de sources authentiques. Le service est en production et prend en charge notamment Vitalink FHIR, eHealthBox REST et certains clients UHMEP. Pour les hôpitaux, le composant choisi détermine les certificats, les jetons, l'enregistrement de client et les renouvellements de clés dont une interface a besoin.
Voici les affirmations sur lesquelles repose la page consacrée à I.AM et I.AM Connect (Identity & Access Management) : des faits courts, formulés par nous, chacun avec sa source et son emplacement vérifiable. Lire l'article · Comment fonctionne l'Atlas.
Affirmations 56 affirmations
| Affirmation | Type | Source | Emplacement | Date de référence |
|---|---|---|---|---|
| I.AM (Identity & Access Management) est le service eHealth intégré d'identification, d'authentification et d'autorisation des acteurs de soins de santé qui demandent l'accès à des services de la plate-forme eHealth et de ses partenaires. ↩ Montrer dans le texte Une erreur ? | fait | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'Wat is de dienst Geïntegreerd gebruikers- en toegangsbeheer/I.AM?' | 26-09-2026 |
| I.AM intègre la gestion des accès, la gestion des utilisateurs et la gestion de l'accès aux données dans un seul système qui distingue quatre contextes techniques: la sécurisation des applications web, des services web SOAP, des services web REST, et l'accès aux données (Data Access). ↩ Montrer dans le texte Une erreur ? | fait | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'Identity & Access management - Technische organisatie' | 26-09-2026 |
| Le service I.AM (Identity & Access Management) assure l'identification, l'authentification et l'autorisation des acteurs des soins de santé; l'utilisateur choisit son profil en fonction de sa qualité telle qu'elle est enregistrée dans la base de données CoBRHA. ↩ Montrer dans le texte Une erreur ? | fait | Welcome Pack (eHealth-platform) — eHealth-platform SRC-6fdf93f016 | p. 15, sectie '3. I.AM' | 25-09-2026 |
| Le certificat permet d'identifier et d'authentifier le partenaire « système » (le logiciel/l'organisation), tandis que l'eID ou un token permet d'identifier et d'authentifier l'utilisateur individuel. ↩ Montrer dans le texte Une erreur ? | fait | eHealth-certificaten | eHealth-platform — eHealth-platform SRC-9bfcb37059 | sectie 'Wat is een eHealth-certificaat?' | 26-09-2026 |
| La spécification IDP (version 1.4, 14/10/2025) distingue trois niveaux de sécurité pour l'authentification et classe itsme, eID et MyGov au niveau High, TOTP au niveau Substantial et nom d'utilisateur/mot de passe au niveau Low. ↩ Montrer dans le texte Une erreur ? | fait | I.AM Identity Provider – Tech Specs v1.4 — eHealth-platform; 14-10-2025 SRC-a5c92698de | p. 8, 4.1 Authentication method | 08-10-2026 |
| De eHealth IDP steunt voor de authenticatie van gebruikers op de BOSA FAS. ↩ Montrer dans le texte Une erreur ? | fait | I.AM Identity Provider – Tech Specs v1.4 — eHealth-platform; 14-10-2025 SRC-a5c92698de | p. 8, §4.1 | 07-10-2026 |
| Selon la spécification IDP (version 1.4), en production, la plupart des applications sont configurées pour une authentification via CSAM FAS, l'utilisateur étant automatiquement redirigé vers le FAS. ↩ Montrer dans le texte Une erreur ? | fait | I.AM Identity Provider – Tech Specs v1.4 — eHealth-platform; 14-10-2025 SRC-a5c92698de | p. 11, 4.2 | 08-10-2026 |
| La spécification IDP (version 1.4) annonce que le « Belgian citizen token » (carte comportant 24 codes personnels) sera prochainement retiré de la liste des méthodes d'authentification disponibles (spécification du 14/10/2025; le moment effectif n'a pas été trouvé). ↩ Montrer dans le texte Une erreur ? | fait | I.AM Identity Provider – Tech Specs v1.4 — eHealth-platform; 14-10-2025 SRC-a5c92698de | p. 11, 4.1.6 Belgian citizen token | 08-10-2026 |
| Après une authentification par eID, itsme ou TOTP, I.AM applique les règles d'accès de l'application et autorise ou non l'accès sur cette base. ↩ Montrer dans le texte Une erreur ? | fait | Geïntegreerd gebruikers- en toegangsbeheer (IAM) — eHealth-platform SRC-e6b4005113 | inleiding | 28-09-2026 |
| Selon le Welcome Pack (version 08/09/2026), les services de base de la Plate-forme eHealth sont: la coordination de processus électroniques partiels, le portail, I.AM, RN Consult, les certificats eHealth, le timestamping, le chiffrement de bout en bout, le répertoire des références (Metahub), eHealthBox et la pseudonymisation & l'anonymisation. ↩ Montrer dans le texte Une erreur ? | fait | Welcome Pack (eHealth-platform) — eHealth-platform SRC-6fdf93f016 | p. 3 (inhoudstafel, rubriek 'Basisdiensten') | 25-09-2026 |
| L'eHealth Welcome Pack décrit I.AM comme un service de base de la plate-forme eHealth, service dont l'intégration est étroitement liée aux architectures proposées par la plate-forme. ↩ Montrer dans le texte Une erreur ? | fait | Welcome Pack (eHealth-platform) — eHealth-platform SRC-6fdf93f016 | p. 17, sectie '5. I.AM', 'Afhankelijkheden, aanbevelingen en waarschuwingen' | 26-09-2026 |
| Pour les applications web classiques côté serveur, l'authentification via I.AM IDP est recommandée (avec Shibboleth SP), tandis que les applications mobiles/natives et les applications REST passent par I.AM Connect. ↩ Montrer dans le texte Une erreur ? | fait | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'Afhankelijkheden, aanbevelingen en waarschuwingen' | 26-09-2026 |
| Pour la sécurisation des services web SOAP, le consommateur du service s'authentifie auprès d'I.AM STS (Secure Token Service) avec un certificat eHealth ou une eID, après quoi le STS délivre un token SAML qui donne accès à plusieurs services web pendant sa période de validité. ↩ Montrer dans le texte Une erreur ? | fait | Beveiliging van webservices | eHealth-platform — eHealth-platform SRC-8846f43048 | sectie 'Veiligheid - WS-Security SAML Token Profile / Holder-of-Key' | 26-09-2026 |
| I.AM Connect est une solution de gestion de l'identité et de l'accès pour les applications web et les services web RESTful, basée sur la norme OIDC (OpenID Connect); l'authentification et l'autorisation des clients s'effectuent via ce service. ↩ Montrer dans le texte Une erreur ? | fait | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | secties 'I.AM Connect' en 'De beveiliging van REST Web Service' | 26-09-2026 |
| I.AM Connect utilise OpenID Connect pour l'authentification et l'autorisation des clients REST. ↩ Montrer dans le texte Une erreur ? | fait | I.AM (Identity & Access Management) — eHealth-platform SRC-e00a751dd4 | La sécurisation de services web REST | 26-09-2026 |
| I.AM AA (Attribute Authority) permet aux partenaires de consulter les sources authentiques eHealth, dont CoBRHA (banque de données des acteurs de soins agréés) et les mandats, indépendamment de l'accès aux applications elles-mêmes. ↩ Montrer dans le texte Une erreur ? | fait | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'I.AM AA (AttributeAuthority)' | 26-09-2026 |
| I.AM AA (Attribute Authority) permet aux partenaires de consulter les sources authentiques eHealth, dont CoBRHA (données relatives aux acteurs des soins de santé) et les mandats. ↩ Montrer dans le texte Une erreur ? | fait | Welcome Pack (eHealth-platform) — eHealth-platform SRC-6fdf93f016 | p. 16, 'I.AM AA (AttributeAuthority)' | 25-09-2026 |
| Selon le cookbook STS WS Trust, la plate-forme eHealth renvoie au consommateur du service web une assertion SAML signée dans un RequestSecurityTokenResponse. ↩ Montrer dans le texte Une erreur ? | fait | STS – WS Trust - Cookbook — eHealth-platform; 04-07-2025 SRC-2c2e9d7ae5 | p. 9, 4 Global overview, Step 2 | 26-09-2026 |
| Selon le cookbook actuel « Beveiliging van webservices », le consommateur du service demande explicitement, à l'étape 1 du processus d'authentification STS, un jeton SAML 1.1 et signe à cette occasion l'appel SOAP selon la policy de sécurité X.509 SHA256. ↩ Montrer dans le texte Une erreur ? | fait | Beveiliging van webservices | eHealth-platform — eHealth-platform SRC-8846f43048 | sectie 'Stap voor stap' - Stap 1 | 26-09-2026 |
| Selon le cookbook STS WS Trust (version 1.2), « SAML2 response » est une valeur acceptée pour l'élément obligatoire TokenType dans la demande d'un token. ↩ Montrer dans le texte Une erreur ? | fait | STS – WS Trust - Cookbook — eHealth-platform; 04-07-2025 SRC-2c2e9d7ae5 | p. 11, tabel RequestSecurityToken, veld TokenType | 08-10-2026 |
| Selon le cookbook STS WS Trust (version 1.2), « SAML1 response » est également une valeur acceptée pour l'élément TokenType. ↩ Montrer dans le texte Une erreur ? | fait | STS – WS Trust - Cookbook — eHealth-platform; 04-07-2025 SRC-2c2e9d7ae5 | p. 11, tabel RequestSecurityToken, veld TokenType | 08-10-2026 |
| Le cookbook STS WS Trust (version 1.2) contient un exemple de réponse pour le TokenType SAML2. ↩ Montrer dans le texte Une erreur ? | fait | STS – WS Trust - Cookbook — eHealth-platform; 04-07-2025 SRC-2c2e9d7ae5 | p. 14-15, 'Reponse example for TokenType SAML2' | 08-10-2026 |
| La refactorisation technique des services TherLink (release R20252.1) touche aussi la gestion des relations thérapeutiques via Metahub et la consultation via l'Attribute Authority; elle correspond à une réécriture complète du code source de tous les composants. ↩ Montrer dans le texte Une erreur ? | fait | Bericht aan de gebruikers van de diensten Metahub en eHealth Therapeutic Links — eHealth-platform (service management); 08-10-2025 SRC-7fad05ed3d | p. 2 (Nederlandse versie), bericht van 08/10/2025 | 25-09-2026 |
| Selon un message de la Plate-forme eHealth du 8 octobre 2025, la mise en production des services TherLink entièrement réécrits était, après un test d'acceptation du 5 au 25 novembre 2025, prévue le 2 décembre 2025. ↩ Montrer dans le texte Une erreur ? | fait | Bericht aan de gebruikers van de diensten Metahub en eHealth Therapeutic Links — eHealth-platform (service management); 08-10-2025 SRC-7fad05ed3d | p. 2, bericht van 08/10/2025 (Nederlandse versie) | 25-09-2026 |
| L'environnement Vitalink FHIR a été mis en production (message du 22 mars 2024) et se trouve à côté de l'environnement KMEHR existant. ↩ Montrer dans le texte Une erreur ? | fait | Nieuwe FHIR-omgeving van Vitalink in productie! — Vitalink (Departement Zorg); 22-03-2024 SRC-a7e3a494e9 | nieuwsbericht | 25-09-2026 |
| Le nouvel environnement Vitalink utilise REST au lieu de SOAP ainsi que les services d'authentification et d'autorisation de la Plate-forme eHealth, basés sur I.AM Connect. ↩ Montrer dans le texte Une erreur ? | fait | Nieuwe FHIR-omgeving van Vitalink in productie! — Vitalink (Departement Zorg); 22-03-2024 SRC-a7e3a494e9 | nieuwsbericht, alinea 3 | 25-09-2026 |
| Vaccinnet 2.0 utilise Vitalink comme source authentique, la norme FHIR, I.AM Connect et des services eHealth comme la pseudonymisation; les couplages KMEHR existants sont restés disponibles jusqu'au déploiement définitif. ↩ Montrer dans le texte Une erreur ? | fait | Vaccinnet integreren in uw softwarepakket — Departement Zorg SRC-401473d268 | sectie 'Overstap naar Vaccinnet 2.0' | 25-09-2026 |
| Pour l'UHMEP FHIR API, un token exchange IAM est obligatoire (I.AM Connect), de sorte que l'exploitant technique n'obtient pas de droits de pseudonymisation. ↩ Montrer dans le texte Une erreur ? | fait | Recip-e FHIR Cookbook (UHMEP-MedicationPrescription-Cookbook.pdf) — Smals / Recip-e; 04-06-2026 SRC-b4bdb9101a | p. 9 (2.3.2 Token Exchange) | 26-09-2026 |
| Pour les variantes REST de l'eHealthBox et de l'Addressbook, un onboarding distinct via I.AM Connect est nécessaire, avec un choix parmi des formulaires d'enregistrement de client pour « Healthcare » (prestataire de soins individuel ou application) ou « M2M » (organisation). ↩ Montrer dans le texte Une erreur ? | fait | Procedure: Onboarding IAM Connect eHealthBox - Addressbook v2.0 — eHealth-platform; 29-05-2024 SRC-771a066b18 | p. 1 | 26-09-2026 |
| La spécification I.AM Connect 1.13 limite le flux client credentials aux clients d'organisation ou d'institution; ce flux n'authentifie aucun utilisateur final. ↩ Montrer dans le texte Une erreur ? | fait | IAM Mobile integration — Technical specifications — eHealth-platform SRC-96b0dd314a | p. 11, 4.2 Client credentials | 26-09-2026 |
| Pour un client-ID d'organisation (machine-to-machine) dans I.AM Connect, une institution de soins utilise le format nihdi-\<type\>-XXXXXXXX, où XXXXXXXX est le numéro INAMI (NIHII) de l'institution. ↩ Montrer dans le texte Une erreur ? | fait | Procedure: Onboarding IAM Connect eHealthBox - Addressbook v2.0 — eHealth-platform; 29-05-2024 SRC-771a066b18 | p. 4 | 26-09-2026 |
| Dans l'API FHIR Recip-e (cookbook v1.0, 04/06/2026), les pharmaciens utilisent le realm M2M avec le client pharmacy. Les pharmacies hospitalières utilisent un client M2M propre et ne peuvent pas réutiliser le client de l'hôpital. ↩ Montrer dans le texte Une erreur ? | fait | Recip-e FHIR Cookbook (UHMEP-MedicationPrescription-Cookbook.pdf) — Smals / Recip-e; 04-06-2026 SRC-b4bdb9101a | p. 6, 2.x Authentication (I.AM Connect) | 26-09-2026 |
| La plate-forme eHealth propose principalement deux types d'architecture: SOAP pour les applications qui tournent sur un seul appareil, et REST pour les applications qui doivent fonctionner simultanément sur plusieurs appareils (pc, smartphone, tablette); pour les nouveaux projets mobiles, REST est privilégié. ↩ Montrer dans le texte Une erreur ? | fait | Architecturen | eHealth-platform — eHealth-platform SRC-0eb97991a9 | sectie 'Inleiding' | 26-09-2026 |
| La plate-forme eHealth exige que les données médicales soient sécurisées au moins au niveau du message (et pas uniquement au niveau du transport), afin que les données ne circulent pas sans protection entre les points du réseau par lesquels elles passent. ↩ Montrer dans le texte Une erreur ? | fait | Architecturen | eHealth-platform — eHealth-platform SRC-0eb97991a9 | sectie 'Vertrouwelijkheid' | 26-09-2026 |
| Un chiffrement end-to-end complet entre l'expéditeur initial et le destinataire final n'est pas strictement nécessaire dans tous les projets, mais la communication doit au moins être sécurisée point-to-point, de sorte que des données médicales ne soient jamais échangées sans protection entre les parties. ↩ Montrer dans le texte Une erreur ? | fait | Architecturen | eHealth-platform — eHealth-platform SRC-0eb97991a9 | sectie 'Vertrouwelijkheid' | 26-09-2026 |
| L'ancien service STS Saml11TokenService (avec l'endpoint iamsaml11tokenservice) n'est plus utilisé depuis octobre 2023; depuis lors, les connecteurs doivent utiliser le nouvel endpoint SecurityTokenService (iamsecuritytokenservice), ce qui confronte encore certaines intégrations à l'erreur « SOA-03005 WSDL compliance failure » lorsque cette adaptation n'a pas été faite. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform services connectors | eHealth-platform — eHealth-platform SRC-ef6afc402c | FAQ 'Hoe pas ik de connector aan naar de nieuwe SecurityTokenService?' | 26-09-2026 |
| Le 7 juillet 2026, la plate-forme eHealth a publié un erratum à sa communication du 11 juin 2026 relative au renouvellement obligatoire des certificats/clés pour les intégrations SAML existantes (IDP/STS/AA) et pour la validation JWT dans I.AM Connect; les clients qui gèrent manuellement leurs métadonnées ou leurs truststores devaient adapter cela avant le 22/07/2026. ↩ Montrer dans le texte Une erreur ? | fait | eHealth Communication: Renewal of I.AM Certificates - Required Actions for SAML and I.AM Connect Integrations (07/07/2026) — eHealth-platform; 07-07-2026 SRC-2e3ed33307 | p. 1 | 26-09-2026 |
| Le message du 07/07/2026 porte le titre « ERRATUM » et indique que les corrections sont mises en évidence en jaune. ↩ Montrer dans le texte Une erreur ? | fait | eHealth Communication: Renewal of I.AM Certificates - Required Actions for SAML and I.AM Connect Integrations (07/07/2026) — eHealth-platform; 07-07-2026 SRC-2e3ed33307 | p. 1, titel en inleiding | 08-10-2026 |
| L'erratum du 07/07/2026 mentionne, aussi bien pour la gestion manuelle des métadonnées que pour la gestion manuelle du truststore des intégrations SAML, l'échéance « avant le 22/07/2026 ». ↩ Montrer dans le texte Une erreur ? | fait | eHealth Communication: Renewal of I.AM Certificates - Required Actions for SAML and I.AM Connect Integrations (07/07/2026) — eHealth-platform; 07-07-2026 SRC-2e3ed33307 | p. 1, SAML-integraties | 08-10-2026 |
| Le message du 11/06/2026 relatif au renouvellement des certificats I.AM mentionne, pour la gestion manuelle des métadonnées des intégrations SAML, « à partir du 26/05/2026 pour ACC et 24/06 pour PRD et avant le 6/10/2026 ». ↩ Montrer dans le texte Une erreur ? | fait | eHealth Communication: Renewal of I.AM Certificates - Required Actions for SAML and I.AM Connect Integrations (bericht 11/06/2026) — eHealth-platform; 11-06-2026 SRC-83aa4238fd | p. 1, SAML-integraties, Manueel metadata-beheer | 08-10-2026 |
| Le message du 11/06/2026 mentionne, pour la gestion manuelle des certificats dans le truststore, la période « à partir du 29/07/2026 et avant le 6/10/2026 » en acceptation et en production. ↩ Montrer dans le texte Une erreur ? | fait | eHealth Communication: Renewal of I.AM Certificates - Required Actions for SAML and I.AM Connect Integrations (bericht 11/06/2026) — eHealth-platform; 11-06-2026 SRC-83aa4238fd | p. 1, SAML-integraties, Manueel beheer van certificaten in de truststore | 08-10-2026 |
| Pour le rollover de la JWT signing key d'I.AM Connect, des moments clés distincts s'appliquaient à l'environnement d'acceptation (nouvelle clé active à partir du 07/07/2026, ancienne clé supprimée le 04/08/2026) et à l'environnement de production (nouvelle clé active à partir du 28/07/2026, ancienne clé supprimée le 26/08/2026). ↩ Montrer dans le texte Une erreur ? | fait | eHealth Communication: Renewal of I.AM Certificates - Required Actions for SAML and I.AM Connect Integrations (07/07/2026) — eHealth-platform; 07-07-2026 SRC-2e3ed33307 | p. 2 | 26-09-2026 |
| Le 28/07/2026, la plate-forme eHealth a annoncé qu'elle migrait sa solution IAM IDP vers une nouvelle version, avec des modifications du look-and-feel. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform communication - 28/07/2026: IDP migration (ACC) — eHealth-platform; 28-07-2026 SRC-9cac292f1a | p. 4, 'VN'-tekst | 08-10-2026 |
| Dans le message du 28/07/2026, chaque partenaire est invité à tester la nouvelle version de l'IDP en acceptation et à confirmer que le client fonctionne encore correctement, avec au minimum le login, le choix du profil, le contenu des access tokens et le logout. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform communication - 28/07/2026: IDP migration (ACC) — eHealth-platform; 28-07-2026 SRC-9cac292f1a | p. 5-6 | 08-10-2026 |
| Selon le message du 28/07/2026, aucune modification n'est attendue de la part des intégrateurs à la suite de la migration de l'IDP dans l'environnement d'acceptation, et la planification du déploiement en production n'est pas encore fixée. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform communication - 28/07/2026: IDP migration (ACC) — eHealth-platform; 28-07-2026 SRC-9cac292f1a | p. 5 | 08-10-2026 |
| Le message du 28/07/2026 relatif à la migration de l'IDP en acceptation s'adresse aux clients IAM Connect; les intégrateurs de l'eHealth IAM IDP ne sont pas visés par ce message et reçoivent une communication distincte. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform communication - 28/07/2026: IDP migration (ACC) — eHealth-platform; 28-07-2026 SRC-9cac292f1a | p. 6 | 08-10-2026 |
| Dans un message du 18/08/2026 adressé à tous les utilisateurs d'un service eHealth dans le domaine *.ehealth.fgov.be, la plate-forme eHealth a demandé de tester un nouveau certificat TLS dans l'environnement d'acceptation à partir du 02/09/2026; le certificat en production serait actif à partir du 13/10/2026. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform communication - 18/08/2026: Replacement of the HARICA Root CA for SSL Certificates *.ehealth.fgov.be — eHealth-platform; 18-08-2026 SRC-7100738e3f | p. 1, punt 2 'Quand devez-vous exécuter ces actions ?' | 08-10-2026 |
| Le message du 18/08/2026 demande d'installer aussi bien la Root CA HARICA 2015 que HARICA 2021. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform communication - 18/08/2026: Replacement of the HARICA Root CA for SSL Certificates *.ehealth.fgov.be — eHealth-platform; 18-08-2026 SRC-7100738e3f | p. 1 | 08-10-2026 |
| Le message du 18/08/2026 indique que les utilisateurs qui se servent des métadonnées TSL en ligne mentionnées dans le message pour valider la chaîne de certificats et la récupérer périodiquement n'ont rien à faire. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform communication - 18/08/2026: Replacement of the HARICA Root CA for SSL Certificates *.ehealth.fgov.be — eHealth-platform; 18-08-2026 SRC-7100738e3f | p. 1, punt 1 | 08-10-2026 |
| Selon une présentation publiée publiquement de la Plate-forme eHealth (30 janvier 2026), Recip-e (services web SOAP) doit passer de SAML v1 à SAML v2, parce que la Plate-forme eHealth l'exige en 2026 pour toutes les applications qui utilisent les services de base eHealth. ↩ Montrer dans le texte Une erreur ? | fait | Réalisations 2025 – Perspectives 2026 (Plate-forme eHealth) — eHealth-platform (publieke presentatie op de persoonlijke website van de administrateur-generaal); 30-01-2026 SRC-88e226b672 | dia 55 ('Elektronisch voorschrift van geneesmiddelen', SAMLv2-migratie, 2026) | 26-09-2026 |
| Un certificat eHealth permet à un prestataire de soins ou à une organisation de s'authentifier en tant que prestataire de soins ou institution reconnue; il est requis dès qu'une suite logicielle souhaite accéder aux services de base eHealth via une connexion de système à système et non une application web. ↩ Montrer dans le texte Une erreur ? | fait | eHealth-certificaten | eHealth-platform — eHealth-platform SRC-9bfcb37059 | sectie 'Wat is een eHealth-certificaat?' | 26-09-2026 |
| Selon le Welcome Pack, l'accès à certains services REST de la plate-forme eHealth exige une intégration avec I.AM Connect; pour l'utilisation du token exchange, des règles supplémentaires et un contrat s'appliquent. ↩ Montrer dans le texte Une erreur ? | fait | Welcome Pack (eHealth-platform) — eHealth-platform SRC-6fdf93f016 | p. 17, sectie '5. I.AM' | 26-09-2026 |
| Pour les intégrations SOAP avec l'eHealthBox, un certificat de base (certificat eHealth) suffit, sans l'étape d'onboarding supplémentaire I.AM Connect qui est exigée pour les services REST. ↩ Montrer dans le texte Une erreur ? | fait | Procedure: Onboarding IAM Connect eHealthBox - Addressbook v2.0 — eHealth-platform; 29-05-2024 SRC-771a066b18 | p. 1 | 26-09-2026 |
| La plate-forme eHealth diffuse sa liste de certificats de confiance (mise à jour du trust store) selon la spécification technique ETSI relative aux listes de confiance (Trusted Lists), de sorte que les logiciels puissent mettre à jour leur trust store de manière sécurisée et automatisable. ↩ Montrer dans le texte Une erreur ? | fait | eHealth-certificaten | eHealth-platform — eHealth-platform SRC-9bfcb37059 | sectie 'Cookbook' - eHealth PlatformTrusted Certificates List | 26-09-2026 |
| Toegang tot de webservices van het eHealth-platform in de acceptatieomgeving vereist een eHealth-certificaat in acceptatie en de integratie van de connector, naast een uitgeteste computer/browser en meestal een medisch testprofiel. ↩ Montrer dans le texte Une erreur ? | fait | Richtlijn betreffende de vernieuwing van de publieke sleutel van een certificaat. | eHealth-platform — eHealth-platform SRC-5e41adfb50 | sectie 'Welke tools zijn vereist om de testen en demo's effectief uit te voeren?' | 26-09-2026 |
| La spécification IDP (version 1.4) décrit les profils SAML 2.0 Web Browser SSO. ↩ Montrer dans le texte Une erreur ? | fait | I.AM Identity Provider – Tech Specs v1.4 — eHealth-platform; 14-10-2025 SRC-a5c92698de | 6.1 SAML 2.0 | 08-10-2026 |
Non reprises dans le texte 9 affirmations
Ces affirmations proviennent des mêmes sources et ont été vérifiées, mais l'article consacré à I.AM et I.AM Connect (Identity & Access Management) ne les utilise pas (encore).
| Affirmation | Type | Source | Emplacement | Date de référence |
|---|---|---|---|---|
| Au 30 octobre 2026, la version française de la page eHealth sur la sécurisation des services web décrit encore que le service consumer demande un jeton SAML 1.1 à l'étape 1 du processus STS. Une erreur ? | fait | Sécurisation des services web | Platform eHealth — Plate-forme eHealth SRC-1c6287ee60 | sectie 'Étape par étape' – Étape 1 | 30-10-2026 |
| Selon la spécification de l'I.AM Identity Provider (version 1.4), itsme est actuellement le seul partenaire reconnu qui offre, à côté des clés numériques des autorités publiques, une clé numérique permettant de se connecter aux services publics. Une erreur ? | fait | I.AM Identity Provider – Tech Specs v1.4 — eHealth-platform; 14-10-2025 SRC-a5c92698de | p. 10, 4.1.2 ItsMe | 30-10-2026 |
| I.AM STS est destiné à l'identification auprès des services web intégrés dans les logiciels des médecins et permet de s'identifier comme médecin, spécialiste ou infirmier. Une erreur ? | fait | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'I.AM STS (Secure Token Service)' | 28-09-2026 |
| Selon la spécification IDP (version 1.4), l'eHealth IDP prend en charge, pour le SSO initié par le SP, une inbound binding publiée dans l'implémentation Shibboleth des profils SAML 1.1 Web SSO. Une erreur ? | fait | I.AM Identity Provider – Tech Specs v1.4 — eHealth-platform; 14-10-2025 SRC-a5c92698de | p. 27-28, 6.2 SAML 1.1 | 08-10-2026 |
| Selon la même spécification, l'échange de tokens d'I.AM STS est autorisé et pris en charge, mais sous certaines limitations. Une erreur ? | fait | IAM STS to IDP/IAM Connect - Cookbook (SSO from fat to thin client) v1.5 — eHealth-platform; 11-09-2026 SRC-a881336f8b | p. 9, 4.2 STS to IAM Connect | 30-10-2026 |
| Le document publié par la plate-forme eHealth au sujet de la mise à niveau du service provider Shibboleth indique qu'eHealth n'a pas encore de plans pour supprimer les profils SAML 1.1 et que ceux-ci restent pris en charge. Une erreur ? | fait | Identity & Authorization Management (I.AM) – SP Shibboleth – Upgrade – Migration from IDP v1.3 to IDP v2 — eHealth platform; 11-07-2013 SRC-3e1616c0a1 | p. 11, 4.4 SAML Protocol, Profile and Binding (optional) | 30-10-2026 |
| Selon le même document, l'IDP eHealth v2 prend en charge tous les profils Web Browser SSO SAML 1.1 et SAML 2.0, de sorte qu'un service provider peut laisser sa configuration telle quelle ou choisir de passer à SAML 2.0. Une erreur ? | fait | Identity & Authorization Management (I.AM) – SP Shibboleth – Upgrade – Migration from IDP v1.3 to IDP v2 — eHealth platform; 11-07-2013 SRC-3e1616c0a1 | p. 11, 4.4 SAML Protocol, Profile and Binding (optional) | 30-10-2026 |
| Selon le cookbook du service web Attribute Authority (version 1.9, 13/10/2026), une valeur d'attribut renvoyée par l'AA peut être pseudonymisée ou non pseudonymisée, et ce pseudonyme est généré par I.AM Connect. Une erreur ? | fait | Attribute Authority WS – Cookbook — eHealth platform; 13-10-2026 SRC-12fdf8b3ff | sectie 5.4.1 (Attribute), beschrijving van AttributeValue | 30-10-2026 |
| La même spécification décrit un flux permettant d'échanger un token SAML holder-of-key d'I.AM STS contre un JWT dans I.AM Connect; ce flux peut aussi servir à démarrer une session web sur la base d'une session SOAP. Une erreur ? | fait | IAM STS to IDP/IAM Connect - Cookbook (SSO from fat to thin client) v1.5 — eHealth-platform; 11-09-2026 SRC-a881336f8b | p. 9, 4.2 STS to IAM Connect | 30-10-2026 |