Content Comparison

...

A.d.h.v. een vertrouwensmiddel wordt een authenticatie token aangemaakt die via een TLS-verbinding tussen de  GBx en ZIM wordt uitgewisseld, op basis van het servercertificaat van het GBx en het servercertificaat van de ZIM. Op basis van het servercertificaat van het GBx wordt vastgesteld vanuit welke organisatie de berichtuitwisseling is geïnitieerd.

Het doel van de authenticatietoken is: 

1. de gebruiker te identificeren en authentiseren
2. de authenticiteit van het verstuurde bericht (deels) te borgen. Hierbij worden elementen uit het verstuurde bericht in het authenticatietoken geplaatst.
3. de gebruiker onweerlegbaar aan het verstuurde bericht te koppelen.

Daarnaast kan t.b.v. authenticatie van de gebruiker in het bericht meerdere tokens opgenomen zijn:

...

Alle XIS-systemen hebben nu voor de authenticatietoken de SALM2 SAML2 standaard gebruikt. Voor de authenticatie van burgers (patiënten) zijn we afhankelijk van DigiD, die ook op SAML2 is gebaseerd. We zullen dus in de FHIR REST interfaces SAML2 (authenticatie) tokens blijven ondersteunen. Het SAML2 (authenticatie) token wordt in XML-vorm opgenomen in de SOAP header van het bericht. De hele SOAP envelop verdwijnt bij het gebruik van een (FHIR) REST service, omdat dit op HTTP gebaseerd is. Hierbij zullen de SAML2 (authenticatie) tokens verplaats worden naar de HTTP "authorization" header in Base64 gecodeerd. Dit heeft de volgende praktische beperkingen:

1. de ontvanger van het bericht moet de HTTP "authorization" header eerst decoderen. Op het LSP doet de XSG de SAML2 (authenticatie) token validatie en controleert of elementen uit het token corresponderen met elementen uit het bericht.
2. in de HTTP standaard is er geen beperking aan de grootte van headers, maar in de praktijk hebben verschillende webservers helaas wel een limiet op de de grootte van headers.
3. Het SAML2 token verwijst naar bepaalde HL7v3 elementen (zoals triggerEventID). Niet al deze elementen uit HL7v3 hebben een gelijksoortig element in FHIR. De specificaties/implementatiehandleiding van de tokens zal voor FHIR/REST uitwisseling daarom sowieso aangepast moeten worden.

In de huidige opzet zou het meesturen van 1 of meerdere SAML2 "assertions" (beweringen) tokens in de HTTP header van het FHIR verzoek mogelijk zijn. Echter bij grotere en meerdere tokens zullen we moeten overgaan op een ander protocol, vanwege de grootte datavolume die webservers niet aankunnen als deze informatie in de HTTP headers worden meegestuurd. De combinatie van SAML2 en REST is voor de XIS-leveranciers mogelijk ook een blokkerend  punt, omdat SAML2 gezien kan worden als een legacy-protocol.

{}