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

I.AM (Identity & Access Management) is de geïntegreerde eHealth-dienst voor identificatie, authenticatie en machtiging van zorgactoren die toegang vragen tot diensten van het eHealth-platform en zijn partners^[1]. Het integreert toegangs-, gebruikers- en gegevenstoegangsbeheer en onderscheidt vier technische contexten: webapplicaties, SOAP-webservices, REST-webservices en gegevenstoegang (Data Access)^[1]. De gebruiker kiest een profiel op basis van zijn hoedanigheid zoals vastgelegd in CoBRHA^[2].

I.AM zorgt dat elke toepassing die eHealth-diensten of partnerdiensten aanroept, op een gemeenschappelijke manier vaststelt wie de gebruiker of het systeem is en in welke hoedanigheid hij optreedt^[1][2]. Het certificaat identificeert het systeem (software/organisatie), de eID of een token de individuele gebruiker^[3].

Status: productie, als basisdienst van het eHealth-platform^[2]. De onderdelen:

• IDP versus Connect: voor klassieke webapplicaties raadt het eHealth-platform I.AM IDP aan; mobiele/native en REST-toepassingen verlopen via I.AM Connect^[1].
• STS: de service consumer authenticeert zich met een eHealth-certificaat of eID bij de STS, die een SAML-token aflevert waarmee binnen de geldigheidsperiode meerdere webservices kunnen worden aangeroepen^[4]. Volgens de STS WS Trust-cookbook (versie 1.2) retourneert eHealth een ondertekende SAML-assertie in een RequestSecurityTokenResponse (RSTR) aan de webserviceconsumer^[5]. Volgens de webpagina 'Beveiliging van webservices' vraagt de consumer daarbij een SAML 1.1-token op, ondertekend volgens de X.509 SHA256-policy^[4].
• I.AM Connect is gebaseerd op OIDC; voor REST-diensten worden klant en autorisatie via OIDC afgehandeld, niet via SAML^[1][6].
• I.AM AA laat partners de authentieke eHealth-bronnen raadplegen, waaronder CoBRHA en mandaten, los van de toegang tot de toepassingen^[1][2]. Ook het beheer van therapeutische relaties loopt deels via I.AM AA; die diensten zouden eind 2025 technisch herschreven worden, met ingebruikname gepland op 2 december 2025^[7]; de effectieve ingebruikname werd niet bevestigd.

Toepassingen: de Vitalink FHIR-omgeving (productie sinds 22/03/2024) gebruikt I.AM Connect^[8], net als Vaccinnet 2.0^[9]. Volgens de Recip-e FHIR-cookbook vereist de UHMEP FHIR-API voor Healthcare-realm-clients de IAM-token-exchange-flow, zodat technische providers geen pseudonimiseringsrechten krijgen^[10] (zie UHMEP en het digitaal verwijsvoorschrift (eReferral)); voor M2M-clients werd dit niet nagegaan. De REST-varianten van eHealthBox en Addressbook vragen een aparte I.AM Connect-onboarding^[11] (zie eHealthBox).

• Clients en realms: bij de onboarding kiest men tussen een client-registratie 'Healthcare' (zorgverlener of applicatie) en 'M2M' (organisatie)^[11]. Volgens de technische specificatie 'IAM Mobile integration' (versie 1.13) is de client-credentials-flow enkel beschikbaar voor organisatie- of instellingsclients en ondersteunt hij geen authenticatie van een eindgebruiker^[12]; een toepassing die namens een individuele zorgverlener handelt, heeft dus een andere flow nodig (afleiding). Een M2M-client-ID van een zorginstelling heeft het formaat nihdi-<type>-XXXXXXXX met het RIZIV-nummer van de instelling^[11]. In de Recip-e FHIR-API gebruiken ziekenhuisapotheken (Ziekenhuisapotheker en het gedeeld medicatieschema) een eigen M2M-client en mogen ze de client van het ziekenhuis niet hergebruiken^[10].
• Architectuurkeuze: het eHealth-platform biedt SOAP aan voor toepassingen op één toestel en REST voor toepassingen op meerdere toestellen; voor nieuwe mobiele projecten krijgt REST de voorkeur^[13].
• Berichtbeveiliging: medische gegevens moeten minstens op berichtniveau beveiligd zijn, niet enkel op transportniveau^[13]; volledige end-to-endversleuteling is niet altijd vereist, maar de communicatie moet minstens point-to-point beveiligd zijn^[13].

• Oude STS-endpoint uitgefaseerd: de service Saml11TokenService (endpoint iamsaml11tokenservice) wordt sinds oktober 2023 niet meer gebruikt; connectoren moeten de SecurityTokenService-endpoint gebruiken, anders volgt de fout 'SOA-03005 WSDL compliance failure'^[14].
• Sleutelvernieuwing 2026: op 7 juli 2026 kondigde het eHealth-platform een verplichte hernieuwing aan van certificaten/sleutels voor bestaande SAML-integraties (IDP/STS/AA) en voor de JWT-validatie in I.AM Connect; wie metadata of truststores manueel beheert, moest dat vóór 22/07/2026 aanpassen^[15]. Voor de JWT signing key golden aparte data: acceptatie nieuwe sleutel 07/07/2026 en oude weg 04/08/2026, productie nieuwe sleutel 28/07/2026 en oude weg 26/08/2026^[15].
• SAML v2 (planning): volgens een publiek gepubliceerde presentatie van Frank Robben voor het personeel van het eHealth-platform (30 januari 2026) moet Recip-e van SAML v1 naar SAML v2, omdat het platform dit in 2026 vereist voor alle toepassingen die basisdiensten gebruiken^[16].

• Technische voorwaarde: elke system-to-systemkoppeling met eHealth-basisdiensten vraagt een eHealth-certificaat^[3]. Toegang tot bepaalde REST-diensten vereist daarbovenop een I.AM Connect-integratie^[2]; voor de REST-varianten van eHealthBox en Addressbook is een aparte I.AM Connect-onboarding vereist^[11]. Vitalink FHIR steunt eveneens op I.AM Connect^[8]; voor Healthcare-realm-clients vereist de UHMEP FHIR-API de IAM-token-exchange-flow^[10].
• Operationeel risico: sleutel- en certificaatvernieuwingen hebben harde data^[15]. Wie truststores manueel beheert, moet die tijdig bijwerken; het eHealth-platform verspreidt zijn vertrouwde certificaten volgens de ETSI-specificatie voor Trusted Lists, zodat dit automatiseerbaar is^[3].
• Aanbeveling (eigen): houd een register bij van alle I.AM-clients (Healthcare/M2M), STS-koppelingen en truststores per toepassing, met een verantwoordelijke per vernieuwingsdatum.

Zie eHealth-certificaten en versleuteling (ETEE) voor certificaten en eHealth-connectoren (eHealth platform services connectors) voor de bibliotheken die STS-authenticatie en versleuteling afhandelen. In de acceptatieomgeving is naast een acceptatiecertificaat ook de connector nodig^[17]. Het overzicht per doeldienst staat op Technische integratie met de eHealth-infrastructuur.

• SAML-versie: de personeelspresentatie van januari 2026 spreekt van een verplichte overstap van SAML v1 naar v2 in 2026^[16], terwijl de webpagina 'Beveiliging van webservices' nog de aanvraag van een SAML 1.1-token beschrijft^[4], de oude Saml11TokenService-endpoint al sinds oktober 2023 uitgefaseerd is^[14], en de officiële mededeling van juli 2026 over sleutelvernieuwing gaat, niet over een protocolversie^[15]. Wat precies verplicht wordt en wanneer, is niet eenduidig.
• Een gepubliceerd migratieplan van SOAP/SAML naar OIDC is niet gevonden (gap).