...
De volgende paragrafen beschrijven de verschillende kenmerken en beveiligingsgerelateerde gegevens die het SAML scantoken onderscheiden, zoals in [IH tokens generiek] beschreven is.
| Code Block |
|---|
<saml:Assertion ... xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> |
Het SAML scantoken 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.
Uniekheid
| Code Block |
|---|
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 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".
Afzender
| Code Block |
|---|
<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:2.16.528.1.1007.3.3:IIext:12345678
Onderwerp
| Code Block |
|---|
<saml:Subject> |
...
<saml:NameID> |
...
950052413 |
...
</saml:NameID> |
...
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches "> |
...
</saml:SubjectConfirmation> |
...
</saml:Subject> |
De Subject verwijst naar de door de zorgverlener/medewerker gevalideerde BSN. De BSN validatie dient plaatsgevonden te hebben door:
...
Vervolgens moet de SubjectConfirmation nog toegevoegd worden:
| Code Block |
|---|
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches "> |
...
</saml:SubjectConfirmation> |
Geldigheid
| Code Block |
|---|
<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 scantoken is getekend) liggen.
...
Het inperken van bepaalde partijen (AudienceRestriction) waarvoor de assertion bedoeld is wordt beschreven in paragraaf 2.4.5 Ontvanger.
Ontvanger
| Code Block |
|---|
<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.
...
urn:IIroot:2.16.840.1.113883.2.4.6.6:IIext:300
Authenticatie
| Code Block |
|---|
<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 het X509 identiteitscertificaat van de uitvoerende zorgverlener/medewerker.
| Code Block |
|---|
<saml:AuthnContext> |
...
<saml:AuthnContextClassRef |
...
>urn:oasis:names:tc:SAML:2.0:ac:classes:X509</saml:AuthnContextClassRef> |
...
</saml:AuthnContext> |
| Code Block |
|---|
</saml:AuthnStatement> |
Afsluiting authentication statement.
Attributen
| Code Block |
|---|
<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.
Zorgaanbieder
| Code Block |
|---|
<saml:Attribute Name="Zorgaanbieder"> |
...
<saml:AttributeValue> |
...
urn:IIroot:2.16.528.1.1007.3.3:IIext:12345678 |
...
</saml:AttributeValue> |
...
</saml:Attribute> |
Het attribuut Zorgaanbieder bevat de URA van de zorgaanbieder van de zorgverlener/medewerker die de BSN validatie heeft uitgevoerd en het token heeft ondertekend. Vanuit het certificaat waarmee het token is ondertekend, kan worden afgeleid wat het URA-nummer van de zorgaanbieder waar de ondertekenaar in dienst is.
...
WID_token (alleen in Scan_token)
| Code Block |
|---|
<saml:Attribute Name="WID_token"> |
...
<saml:AttributeValue> |
...
Base64 representatie van het WID_token |
...
</saml:AttributeValue> |
...
</saml:Attribute> |
Het attribuut WID_token bevat de gehele SAML assertion ondertekend met het ZID servercertificaat Base64 geëncodeerd.
...
WID_raw_data (alleen in WID_token)
| Code Block |
|---|
<saml:Attribute Name="WID_raw_data"> |
...
<saml:AttributeValue> |
...
Base64 representatie van de ingescande Datagroep 11 |
...
</saml:AttributeValue> |
...
</saml:Attribute> |
Het attribuut WID_raw_data bevat de volledig ingescande datagroep 11 uit het WID. Het element is Base64 geëncodeerd.
...
Indien het element base64 gedecodeerd wordt is de structuur in JSON als volgt:
| Code Block |
|---|
{"type": "3", |
...
"version": "1", |
...
"attributes": |
...
[{"dg11": "<dg11 value>"}], |
...
"sod": "<sod value>" |
...
} |
Waarbij:
“dg11” de data uit datagroep 11 bevat en
...
Het attributen statement blok ziet er dan bijvoorbeeld zo uit (de volgorde van de attributen is niet relevant):
| Code Block |
|---|
<saml:AttributeStatement> |
...
<saml:Attribute Name="Zorgaanbieder"> |
...
<saml:AttributeValue> |
...
urn:IIroot:2.16.528.1.1007.3.3:IIext:12345678 |
...
</saml:AttributeValue> |
...
</saml:Attribute> |
...
<saml:Attribute Name="WID_token"> |
...
<saml:AttributeValue> |
...
Base64 representatie van het WID_token |
...
</saml:AttributeValue> |
...
</saml:Attribute> |
...
</saml:AttributeStatement> |
Tenslotte wordt het attributen statement blok afgesloten met
| Code Block |
|---|
</saml:AttributeStatement> |
Algoritmes
Om de integriteit en onweerlegbaarheid van het SAML scantoken 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 identiteits-certificaat van de verzender en de CA certificaten zoals verstrekt door ZORG-ID, onomstotelijk vaststellen dat het SAML scantoken ondertekend is met de privé sleutel behorend bij het gebruikte certificaat van de zorgmedewerker en dat het WID_token ondertekend is met de privé sleutel van het ZORG-ID servercertificaat.
...
Eerst wordt het SAML scantoken – het <saml:Assertion ...> element aangemaakt en gevuld met die elementen, zoals beschreven in paragraaf 2.4 Inhoud.
| Code Block |
|---|
<saml:Assertion |
...
ID="token_2.16.528.1.1007.3.3.1234567.1_0123456789" |
...
IssueInstant="2009-06-24T11:47:34Z" |
...
Version="2.0" |
...
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> |
...
... Zie paragraaf 2.4 Inhoud ... |
...
</saml:Assertion> |
Het XML Signature blok is onderdeel van het SAML scantoken. Het XML Signature blok komt na het <saml:Issuer> element. Na de Signature volgt de rest van de inhoud van de assertion.
| Code Block |
|---|
<saml:Assertion |
...
ID="token_2.16.528.1.1007.3.3.1234567.1_0123456789" |
...
IssueInstant="2009-06-24T11:47:34Z" |
...
Version="2.0" |
...
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> |
...
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"> |
...
urn:IIroot:?:IIext:? |
...
</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> |
...
<wss:SecurityTokenReference> |
...
<ds:X509Data> |
...
... |
...
</ds:X509Data> |
...
<wss:SecurityTokenReference> |
...
</ds:KeyInfo> |
...
</ds:Signature> ... |
...
... Zie paragraaf 2.3 Inhoud ... |
...
</saml:Assertion> |
Indien de Signature aangemaakt wordt moet niet meer met de strings (saml:Assertion en SignedInfo) gemanipuleerd worden, maar ze moeten octet-voor-octet overgenomen worden in het bericht. Strikt genomen is het toegestaan wijzigingen aan te brengen die door canonicalisatie bij de ontvanger weer opgeheven worden, maar wanneer de digitale handtekening door middel van strings wordt opgebouwd, is het een foutgevoelige handeling.
...