Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

In dit hoofdstuk wordt de inhoud van het SAML inschrijftoken besproken. Het SAML inschrijftoken bevat de, binnnen een zorgorganisatie, gevalideerde BSN en is ondertekend door een zorgverlener/medewerker. Het SAML inschrijftoken is een op XML gebaseerde SAML assertion en heeft tot doel de assertions (bewijs van een bewering) over te brengen tussen partijen.
Alle XML voorbeelden in het document dienen door de betrokken partijen tijdens het bouwen van de uitwisseling getest, en waar nodig, in samenspraak met VZVZ aangepast te worden voor een juiste optimale werking.

Anchor
_Toc298160208
_Toc298160208
Anchor
_Toc304817132
_Toc304817132
Anchor
_Toc18420241
_Toc18420241
Structuur



Wiki Markup
Het SAML inschrijftoken is een afgegeven SAML assertion met betrekking tot de gevalideerde BSN die gebruikt wordt bij berichtauthenticatie voor het landelijk EPD. Het SAML inschrijftoken is ondertekend met behulp van een UZI-pas van een zorgverlener/medewerker. Er wordt gebruik gemaakt van SAML v2.0 \[SAML Core\].



Anchor
_Toc424716306
_Toc424716306
Anchor
_Toc18420242
_Toc18420242
Assertion

De assertion heeft de volgende structuur (de waarden die in het token gebruikt worden zijn fictief):

Element/@Attribute

0..1

Omschrijving

@ID

1

Unieke identificatie van de Assertion

@Version

1

Versie van het SAML Protocol. Vaste waarde moet zijn 2.0

@IssueInstant

1

Tijdstip van uitgifte van de Assertion.

Issuer

1

De URA van de zorgaanbieder organisatie waarbinnen de face to face controle heeft

plaatsgevonden

plaatsgevonden of het WID is ingescand in combinatie met een F2F controle.

@NameQualifier

0

Niet gebruiken

@SPNameQualifier

0

Niet gebruiken

@Format

1

Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"

@SPProviderID

0

Niet gebruiken

Signature

1

Bevat de handtekening over de assertion zoals gezet met behulp van de UZI pas van de zorgverlener (Z) of de UZI medewerkerpas van de medewerker (N). De handtekening dient geplaatst te zijn met behulp van het authenticatie certificaat op de pas.

De handtekening kan ook gezet zijn met het identiteitscertificaat van de medewerker die uitgegeven is door ZORG-ID

Subject

1

BSN van de patient waarvan de BSN gevalideerd is.

BaseID

0

Niet gebruiken

NameID

1

Bevat de gevalideerde BSN.

EncryptedID

0

Niet gebruiken

SubjectConfirmation

1

Moet aanwezig zijn.

@Method

1

'urn:oasis:names:tc:SAML:2.0:cm:sender-vouches'

SubjectConfirmationData

1

Bevat Keyinfo

@Recipient

0

Niet gebruiken

@NotOnOrAfter

0

Niet gebruiken

@InResponseTo

0

Niet gebruiken

@NotBefore

0

Niet gebruiken

@Address

0

Niet gebruiken

KeyInfo

1

Bevat de X509 Issuer.serial van de medewerkerspas of zorgverlenerpas.

Of het publieke deel van het door ZORG-ID aangemaakte identiteitscertificaat.

Conditions

1

Moet aanwezig zijn.

@NotBefore

1

Moet aanwezig zijn.

@NotOnOrAfter

1

Moet aanwezig zijn. Mag maximaal 1,5 jaar na @NotBefore liggen.

Condition

0

Niet gebruiken

AudienceRestriction

1

Moet aanwezig zijn

Audience

1..*

Minimaal 1 element: urn:IIroot:2.16.840.1.113883.2.4.6.6:IIext:1 (is de ZIM). Meerdere audiences zijn toegestaan.

ProxyRestriction

0

Niet gebruiken

Advice

0

Niet gebruiken

AuthnStatement

1

Moet aanwezig zijn

@AuthnInstant

1

Tijdstip van BSN validatie. Dit mag t.b.v. het werkproces ook de 'timestamp' zijn van het moment van aanmaken van het inschrijftoken of het tijdstip van inscannen van het WID.

@SessionIndex

0

Niet gebruiken

AuthnContext

1

Moet aanwezig zijn

AuthnContextClassRef

1

1

urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI of

urn:oasis:names:tc:SAML:2.0:ac:classes:

SmartcardPKI

X509

AttributeStatement

0..

1

Moet aanwezig zijn

Attribute

1

Moet aanwezig zijn.

@Name

1

Vaste waarde: "Uitvoerder"

AttributeValue

1

De UZI van de zorgverlener of medewerker die het token heeft ondertekend.

    Attribute

0..1

Alleen aanwezig indien het een inschrijftoken op basis van een ingescand WID betreft.

        @Name

0..1

Vaste waarde “Scantoken”

    AttributeValue

0..1

Het scantoken Base64 geencodeerd. Voor het Scantoken zie AORTA_Auth_IH_Scantoken

N.B.: bovenstaande tabel bevat de meest gebruikte elementen van SAML assertions en is derhalve niet volledig. Voor niet genoemde elementen geldt: Niet gebruiken.

...

Het SAML inschrijftoken die gebruikt wordt bij berichtauthenticatie maakt gebruik van de volgende namespaces. De prefixen zijn niet normatief maar worden in dit document als voorbeelden gebruikt.
Tabel

Anchor
ex_AORTA_STK_t3300
ex_AORTA_STK_t3300
AORTA.STK.t3300 – Namespaces

Prefix

Namespace URI

ds

http://www.w3.org/2000/09/xmldsig#

saml

urn:oasis:names:tc:SAML:2.0:assertion

wss

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd


Image Modified

Bij het gebruik van de namespace-prefixes is het van belang deze na het ondertekenen niet meer te veranderen, dit maakt de digitale handtekening ongeldig.

Anchor
_Ref284490514
_Ref284490514
Anchor
_Ref284490520
_Ref284490520
Anchor
_Ref284490529
_Ref284490529
Anchor
_Toc298160210
_Toc298160210
Anchor
_Toc304817134
_Toc304817134
Anchor
_Toc18420244
_Toc18420244
Inhoud



Wiki Markup
De volgende paragrafen beschrijven de verschillende kenmerken en beveiligingsgerelateerde gegevens die het SAML inschrijftoken onderscheiden, zoals in \[IH tokens generiek\] beschreven is.
\\
<saml:Assertion ... xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
\\
Het SAML inschrijftoken begint met het Assertion element en een verwijzing naar de XML SAML namespace voor SAML 2.0 assertions. De attributen behorende bij het Assertion element wordt in paragraaf 2.4.1 Uniekheid beschreven.
\\



Anchor
_Ref284492444
_Ref284492444
Anchor
_Ref284492449
_Ref284492449
Anchor
_Ref284492769
_Ref284492769
Anchor
_Ref284492774
_Ref284492774
Anchor
_Toc298160211
_Toc298160211
Anchor
_Toc304817135
_Toc304817135
Anchor
_Toc18420245
_Toc18420245
Uniekheid

ID="token_dd1c1f96-f0b0-4026-a978-4d724c0a0a4f"
IssueInstant="2009-06-24T11:47:34Z"
Version="2.0">
De volgende attributen van het SAML assertion element maken van de SAML assertion een uniek gegeven, uitgegeven door de verzender van het bericht. Het attribuut ID identificeert op een unieke wijze de assertion. De waarde moet mondiaal uniek zijn voor AORTA berichten, zodat bij samenvoegen van meerdere XML bestanden (in een HL7v3 batch of anderszins) de waarde uniek blijft.
Het wordt aanbevolen een UUID (Universally Unique Identifier) te gebruiken. Bij het gebruik van andere vormen is er een kans, hoe klein ook, dat een ID samenvalt met een ID gemaakt volgens een andere methode van een andere leverancier).

Image Modified

Een ID in XML mag niet met een cijfer beginnen. Bij het gebruik van een UUID is het dus aan te raden een prefix te gebruiken, welke met een letter of underscore ('_') begint.


Het attribuut IssueInstant is een tijdsmoment van uitgifte van de SAML assertion. De tijdswaarde is gecodeerd in UTC. Het attribuut Version is de gebruikte SAML versie van de SAML assertion. De aanduiding voor de versie van SAML gedefinieerd in deze specificatie is "2.0".

Anchor
_Ref284431484
_Ref284431484
Anchor
_Ref284431491
_Ref284431491
Anchor
_Toc298160214
_Toc298160214
Anchor
_Toc304817138
_Toc304817138
Anchor
_Toc18420246
_Toc18420246
Afzender

<saml:Issuer>
<!-- De Issuer verwijst naar de organisatie waarbinnen de BSN validatie heeft plaats gevonden.-->
urn:IIroot:2.16.528.1.1007.3.3:IIext:12345678
</saml:Issuer>
De URA wordt uitgedrukt met behulp van een URN (Uniform Resource Name). De URN is opgebouwd uit:
"urn:IIroot:"<OID voor UZI organisatieIds>":IIext:"<URA>
De URN string is opgebouwd uit een IIroot en een IIext. "II" staat voor het HL7v3 datatype Instance Indentifier. Om de namespace in URN uniek te krijgen is II als prefix voor de root en ext geplaatst.
URA's worden uitgedrukt als een id onder het identificatiesysteem "2.16.528.1.1007.3.3". De URA wordt toegekend door het UZI-register. Stel dat de URA de waarde "12345678" heeft, dan ziet de URN er als volgt uit:
urn:IIroot:2.16.528.1.1007.3.3:IIext:12345678

Anchor
_Ref284492378
_Ref284492378
Anchor
_Ref284492385
_Ref284492385
Anchor
_Toc298160212
_Toc298160212
Anchor
_Toc304817136
_Toc304817136
Anchor
_Toc18420247
_Toc18420247
Onderwerp

...


Vervolgens moet de SubjectConfirmation nog toegevoegd worden:
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches ">
</saml:SubjectConfirmation>

Anchor
_Ref284492429
_Ref284492429
Anchor
_Ref284492435
_Ref284492435
Anchor
_Toc298160213
_Toc298160213
Anchor
_Toc304817137
_Toc304817137
Anchor
_Toc18420248
_Toc18420248
Geldigheid

<saml:Conditions
NotBefore="2009-06-24T11:47:34Z"
NotOnOrAfter="2010-12-24T11:47:34Z">
Het attribuut NotBefore is de tijd waarop de SAML assertion geldig wordt. NotBefore moet altijd op of na de aanvang van de geldigheidsdatum van het certificaat (waarmee het inschrijftoken is getekend) liggen.

Image Modified

Wordt een bericht met een inschrijftoken ontvangen voor NotBefore is aangevangen, dan moet dit bericht geweigerd worden.


Het attribuut NotOnOrAfter is de tijd waarop de SAML assertion vervalt. NotOnOrAfter mag na het verstrijken van de geldigheid van het certifcaat (waarmee het inschrijftoken is getekend) liggen.

Image Modified

Wordt een bericht met een inschrijftoken ontvangen op of nadat NotOnOrAfter is verstreken, dan moet dit bericht geweigerd worden.


Deze tijd is als bovenstaande tijd geformatteerd. Het maximaal toegestane verschil tussen NotBefore en NotOnOrAfter is anderhalf jaar.

Image Modified

De geldigheidsduur van een inschrijftoken (NotOnOrAfter minus NotBefore) kan langer zijn dan de geldigheidsduur van het authenticatiecertificaat waarmee het token wordt getekend.


Indien het certificaat waarmee het inschrijftoken is getekend op de CRL is geplaatst, dan dient het inschrijftoken niet geweigerd te worden door het LSP. Het is op de CRL niet inzichtelijk om welke reden een certificaat op de CRL is geplaatst. Dit kunnen uiteenlopende redenen zijn zoals een verloren pas of een intrekking van een BIG-registratie. Om het zorgproces niet te frustreren wordt deze controle procesmatig opgepakt door Security Management.
Echter, bij het ondertekenen van het inschrijftoken moet er een geldig certificaat gebruikt worden. Indien bij ondertekening van het inschrijftoken het certificaat al op de CRL is geplaatst, dan dient het inschrijftoken wel geweigerd te worden.

Image Modified

Indien het certificaat vóór ondertekening van het inschrijftoken op de CRL is geplaatst, dan dient het inschrijftoken geweigerd te worden door het LSP.


Image Modified

Indien het certificaat na ondertekening van het inschrijftoken op de CRL is geplaatst, dan dient het inschrijftoken niet geweigerd te worden.


Het inperken van bepaalde partijen (AudienceRestriction) waarvoor de assertion bedoeld is wordt beschreven in paragraaf 2.4.5 Ontvanger.

Anchor
_Ref284492345
_Ref284492345
Anchor
_Ref284492352
_Ref284492352
Anchor
_Ref284492808
_Ref284492808
Anchor
_Ref284492816
_Ref284492816
Anchor
_Toc298160215
_Toc298160215
Anchor
_Toc304817139
_Toc304817139
Anchor
_Toc18420249
_Toc18420249
Ontvanger

<saml:AudienceRestriction>
<!-- Root en extensie van de ZIM -->
<saml:Audience>urn:IIroot:2.16.840.1.113883.2.4.6.6:IIext:1</saml:Audience>
</saml:AudienceRestriction>
In de AudienceRestriction wordt beschreven aan wie de SAML assertion is gericht. In ieder geval dient de ZIM als audience voor te komen (IIext:1). Meerdere Audience elementen is toegestaan.
Voor de <Audience> parameter is gekozen voor URN. De URN string is opgebouwd uit een IIroot en een IIext. "II" staat voor het HL7v3 datatype Instance Indentifier. Om de namespace in URN uniek te krijgen is II als prefix voor de root en ext geplaatst.
AORTA Applicatie-id's worden uitgedrukt als een id onder het identificatiesysteem "2.16.840.1.113883.2.4.6.6". Het correcte applicatie-id voor de GBZ-applicatie wordt toegekend bij aansluiting op de AORTA. Stel dat dit "300" zou zijn, dan ziet de URN er als volgt uit:
urn:IIroot:2.16.840.1.113883.2.4.6.6:IIext:300

Anchor
_Ref284492318
_Ref284492318
Anchor
_Ref284492326
_Ref284492326
Anchor
_Toc298160216
_Toc298160216
Anchor
_Toc304817140
_Toc304817140
Anchor
_Toc18420250
_Toc18420250
Authenticatie



Wiki Markup
<saml:AuthnStatement
 AuthnInstant="2009-06-24T11:47:34"
 SessionIndex="token_2.16.528.1.1007.3.3.1234567.1_0123456789">
 \\
Het subject, de gevalideerde BSN, in de SAML assertion is geauthenticeerd door middel van een authenticatiemiddel van de uitvoerende zorgverlener/medewerker.
\\
<saml:AuthnContext>
  <saml:AuthnContextClassRef
>urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI</saml:AuthnContextClassRef>
</saml:AuthnContext>
\\
Binnen de gebruikte applicatie beveiligingsstandaarden is er sprake van verschillende vertrouwensniveaus.
\\
Binnen de SAML-specificatie geeft men een authenticatie-context ({_}AuthnContext{_}) mee die de context van het gebruikte authenticatiemiddel aangeeft. Hiervoor zijn een aantal contexten gespecificeerd, zie \[SAMLAuthnContext\], die gebruikt worden als referentiekader voor de communicatie tussen de ZIM en andere componenten zoals GBZ applicaties.
\\
Uitgaande van de beveiligingsniveaus van GBZ, zorgverlener/medewerker en UZI-pas wordt het "{_}urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI{_}" beveiligingsniveau gehanteerd om het AORTA vertrouwensniveau midden voor zorgverleners weer te geven.
\\
</saml:AuthnStatement>
Afsluiting authentication statement.
\\



Anchor
_Ref284492274
_Ref284492274
Anchor
_Ref284492279
_Ref284492279
Anchor
_Toc298160217
_Toc298160217
Anchor
_Toc304817141
_Toc304817141
Anchor
_Toc18420251
_Toc18420251
Attributen

<saml:AttributeStatement>
De volgorde van de attributen in het AttributeStatement is niet relevant. Er mogen geen andere attributen opgenomen worden in het AttributeStatement dan hier beschreven is.
Uitvoerder
<saml:Attribute Name="Uitvoerder">
<saml:AttributeValue>123456789</saml:AttributeValue>
</saml:Attribute>
Het attribuut Uitvoerder bevat het UZI van de zorgverlener/medewerker die de BSN validatie heeft uitgevoerd en het token heeft ondertekend. Indien deze nog niet bekend is bij het aanmaken van het inschrijftoken, dan kan dit veld leeg gelaten worden. Vanuit het certificaat waarmee het token is ondertekend, kan dan worden afgeleid wat het UZI-nummer van de ondertekenaar was.
attributeStatement blok
Het attributen statement blok ziet er dan bijvoorbeeld zo uit (de volgorde van de attributen is niet relevant):
<saml:AttributeStatement>
<saml:Attribute Name="Uitvoerder">
<saml:AttributeValue>123456789</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
Tenslotte wordt het attributen statement blok afgesloten met
</saml:AttributeStatement>

Anchor
_Toc298160218
_Toc298160218
Anchor
_Toc304817142
_Toc304817142
Anchor
_Toc18420252
_Toc18420252
Algoritmes



Wiki Markup
Om de integriteit en onweerlegbaarheid van het SAML inschrijftoken te waarborgen wordt een XML Signature geplaatst, zoals beschreven in \[IH tokens generiek\]. Na plaatsen van de XML Signature kan de ontvanger, met gebruikmaking van het persoonsgebonden UZI-certificaat van de verzender en de CA certificaten zoals verstrekt door het UZI-register, onomstotelijk vaststellen dat het SAML inschrijftoken ondertekend is met de privé sleutel behorend bij het gebruikte certificaat van de zorgmedewerker.
\\
De XML Signature van het SAML inschrijftoken die gebruikt wordt bij berichtauthenticatie met behulp van de UZI-pas maakt gebruik van de volgende algoritmes, zoals beschreven in \[IH tokens generiek\]:



  • Voor het berekenen van de hashwaarde wordt SHA-256 gebruikt.
  • Voor de digitale handtekening in AORTA wordt gebruik gemaakt van een RSA handtekening over een SHA-256 digest.


<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="f5a1a568-10ee-435b-811e-3b0111f654e9"><ac:plain-text-body><![CDATA[

!worddavd4f5470fa11a21c7aa70e787c54ee381.png

height=43,width=43!

Omdat de XML Signature onderdeel is van het SAML inschrijftoken en in het SAML inschrijftoken geplaatst wordt, moet er een "enveloped-signature" transformatie uitgevoerd worden die de Signature tags uit het SAML inschrijftoken verwijderd gevolgd door een "exc-c14n transformatie" (zie ook [SAML Core] §5.4.3 en §5.4.4).

]]></ac:plain-text-body></ac:structured-macro>


Anchor
_Toc298160219
_Toc298160219
Anchor
_Toc304817143
_Toc304817143
Anchor
_Toc18420253
_Toc18420253
Opbouw

...

  • Neem het SignedInfo blok op.
  • Neem de SignatureValue op.
  • Neem certificaatgegevens in het KeyInfo blok op, in de vorm van een verwijzing (X509IssuerSerial).


Image Modified

Wanneer een bericht een SAML assertion bevat, moet dat bericht precies één bijbehorende digitale handtekening bevatten.


Het maken van de XML Signature uit strings levert de SAML assertion op met daarin de Signature.

Anchor
_Toc298160221
_Toc298160221
Anchor
_Toc304817145
_Toc304817145
Anchor
_Toc18420255
_Toc18420255
Plaats van het SAML token en de digitale handtekening

Het SAML inschrijftoken met daarin de digitale handtekening wordt in het WS-Security SOAP Header gezet. Op het <wss:Security> element moet een soap:mustUnderstand="1" vlag opgenomen worden, die aangeeft dat de ontvanger dit security element moet verwerken en een soap:actor="http://www.aortarelease.nl/actor/zim" die aangeeft dat de ZIM dit security element verwerkt.
<soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
...
<wss:Security xmlns:wss=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
soap:actor="http://www.aortarelease.nl/actor/zim" soap:mustUnderstand="1">
<saml:Assertion ... >
<saml:Issuer>...</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
...
</ds:SignedInfo>
<ds:SignatureValue>Wuwn...5e4=</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
...
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
... Zie paragraaf 2.3 Inhoud ...
</saml:Assertion ... >
</wss:Security>
</soap:Header>