Verificatie van het bericht

Het is belangrijk vast te stellen dat de velden in het SAML inschrijftoken een correcte waarde hebben en geldig ondertekend zijn. Wanneer dit niet zou gebeuren, kan een kwaadwillende met een gestolen token nog steeds gegevens opvragen van bv. ieder willekeurig burgerservicenummer.

De ontvanger controleert of de WS-Security SOAP Header voor hem bestemd is, zie soap attribuut actor.

Het SAML inschrijftoken wordt door de ontvanger uit de WS-Security SOAP Header gehaald indien de WS-Security SOAP Header voor de ontvanger bestemd is en dat de ontvanger deze moet verwerken. Bij gebruik van het SAML inschrijftoken moet de ontvanger controleren of:

• De aanduiding voor de versie van SAML gedefinieerd is op "2.0", zie Uniekheid  ;
• De juiste organisatieID is opgenomen die deze assertion heeft gecreëerd en de gebruiker heeft geauthenticeerd, zie Afzender. Het zorgaanbiederID in het token dient overeen te komen met de zorgaanbiederID in het bericht. Tevens dient de zorgaanbiederID overeen te komen met:
• De URA van het transactietoken
• De URA uit het mandaattoken
• Het BSN uit het Subject zie Onderwerp overeenkomt met het BSN uit het transactietoken en het BSN uit het HL7-bericht;
• De Assertion correct is ondertekend door de Signature te valideren met het gerefereerde certificaat.
• Het gebruikte certificaat waarmee de ondertekening heeft plaatsgevonden geldig was ten tijde van de ondertekening.
• Indien het certificaat op de CRL is geplaatst, dan dient dit plaats te hebben gevonden nadat het token gegenereerd en ondertekend is.
• De relevante certificaatketen te valideren op geldigheid.
• De geldigheidsperiode van het token, zie Geldigheid , niet langer is dan 1,5 jaar;
• Het bericht ontvangen is binnen de geldigheidsperiode van het token, zie Geldigheid ;
• De afnemer van het SAML inschrijftoken (audience) minimaal de ZIM is, zie Ontvanger  ;
• De zorgverlener/zorgmedewerker is geauthenticeerd via het voorgedefinieerde authenticatiemiddel, de SmartCardPKI, zoals beschreven in Authenticatie ;
• Alleen die attributen zijn gedefinieerd, die zijn beschreven in Attributen ;
• Indien het inschrijftoken ondertekend is met een UZI certificaat: de attribuutwaarde van Uitvoerder overeenkomt met het UZI-nummer van het gerefereerde certificaat,  zie Attributen ;
• Indien het inschrijftoken ondertekend is met het identiteitscertificaat van ZORG-ID dienen de volgende extra controles plaats te vinden:
• Het attribuut Scantoken dient aanwezig te zijn met hierin het Base64 geencodeerde scantoken
• Het scantoken dient gedecodeerd en vervolgens gevalideerd te worden,zie [Scantoken].
• Het verleningstoken dient gedecodeerd en vervolgens gevalideerd te worden, indien het attribuut Verlengingstoken aanwezig is.
• Het subject uit het inschrijftoken (BSN) dient overeen te komen met de waarde van het subject uit het scantoken.
• De AuthnInstant uit het inschrijftoken (DatumTijd) dient overeen te komen met de waarde van het AuthnInstant attribuut uit het scantoken.
• De attribuutwaarde van Uitvoerder overeenkomt met de Common Name van het meegestuurde certificaat, zie Attributen

Het inschrijftoken mag meerdere malen gebruikt worden.

Het tokenID dient in de log van de ZIM opgenomen te worden.

Als aan één van de bovenstaande condities niet is voldaan, moet het bericht door de ontvanger geweigerd worden en een SOAP foutmelding aan het verzendende systeem afgegeven worden, zie foutafhandeling in [IH tokens generiek].

Als wel aan alle condities is voldaan, wordt het HL7v3 bericht verder verwerkt.

{}