Bestemming en verwerking

WS-Security informatie kan voor verschillende bestemmingen (GBx’en en ZIM) bedoeld zijn. In [IH Transport] wordt uitleg gegeven over het gebruik van de bestemming en verwerking attributen. In [IH Transport] wordt aangegeven welke soap:actor attributen gebruikt moeten worden per bestemming.

Het volgende blok is een implementatievoorbeeld van de bestemming en verwerking van WS-Security.

<soap:Header ...>

  ...

  <wss:Security xmlns:wss=

    "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"

    soap:actor="http://www.aortarelease.nl/actor/zim" soap:mustUnderstand="1">

    ...

  </wss:Security>

</soap:Header>

Er is één WS-Security header per bestemming. Er zijn dus maximaal twee WS-Security headers: één voor de ZIM, één voor het GBx. Een security header kan meer dan één security token bevatten. De security header gericht aan de ZIM wordt bij voorkeur vóór de security header van een GBZ geplaatst; daarmee kunnen ze verwerkt worden in de volgorde waarin ze nodig zijn.

Verificatie en controle

In de verschillende beveiligingsimplementatie handleidingen in AORTA en in

[IH Transport] worden aanvullende voorwaarden gesteld i.h.k.v. verificatie en controle.

Bij ontvangst van het security token dient de ontvanger de volgende controles uit te voeren:

• voldoet de XML Signature aan de eisen die er in [XMLSIG] aan gesteld worden;
• voldoet het security token aan de eisen die er in dit document aan gesteld worden;
• valideert de signature over het security token conform de eisen die er in dit document aan gesteld worden;
• is het gebruikte certificaat correct getekend, evenals de certificaten tot een vertrouwd certificaat;
• is het gebruikte certificaat geldig, niet verlopen en niet ingetrokken;
• is er een match tussen het bericht en het security token conform de eisen die de (zorg)toepassing daaraan stelt.

Indien één van de controles niet bevestigd wordt, wordt een SOAP fout gegenereerd, zie paragraaf 6.3 Foutafhandeling. Indien een SOAP fout wordt gegenereerd mag het bericht door de ontvangende partij verder verwerkt worden wanneer de betreffende toepassing dat vereist.

Foutafhandeling

De volgende SOAP fouten zijn van toepassing bij security tokens. Op de eerste SOAP foutmelding na, zijn ze onderdeel van WS-Security.

Tabel  AORTA.STK.t3150

De volgende foutmeldingen worden daar aan toegevoegd.

Tabel AORTA.STK.t3160

De volgende statuscodes (URI referenties) worden door SAML onderkend en geretourneerd [SAML Core].

Een statuscode is een Uniforme Resource Name (URN) en is als volgt opgebouwd:

"urn:"<Namespace Identifier>":"<Name Specific String>

Voorbeeld:

"urn:oasis:names:tc:SAML:2.0:status:Success"

In de <statuscode> tabel AORTA.STK.t3170 wordt alleen de omschrijving en de specifieke string (<Name Specific String>) getoond. <StatusDetail> kan daarnaast gebruikt worden om een specifieke leesbare melding te retourneren (zie [SAML Core]).

Tabel AORTA.STK.t3170

Loggen

Per security token wordt bepaald wat er gelogd moet worden door het LSP. Dit is opgenomen in de IH's van de verschillende tokens. In ieder geval dient van elk op het LSP binnenkomend token die getekend is door een UZI-certificaat, het certifcaatID van het UZI-certificaat gelogd te worden.

{}