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.

...

...

Structuur

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].

...


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 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

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

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

AttributeStatement

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.

...

...

Namespaces

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 Anchorex_AORTA_STK_t3300ex_AORTA_STK_t3300 AORTATabel 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

...

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.

...

Inhoud

De volgende paragrafen beschrijven de verschillende kenmerken en beveiligingsgerelateerde gegevens die het SAML inschrijftoken onderscheiden, zoals in [IH tokens generiek] beschreven is.

...

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.

...


Uniekheid

...

ID="token_dd1c1f96-f0b0-4026-a978-4d724c0a0a4f"
IssueInstant="ID="token_dd1c1f96-f0b0-4026-a978-4d724c0a0a4f"
IssueInstant="2009-06-24T11:47:34Z"
Version="2.0">

...


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

<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 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

...

Onderwerp

<saml:Subject>
    <saml:NameID>
    950052413
   </saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches ">
    </saml:SubjectConfirmation>
</saml:Subject>

...


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

...

Geldigheid

<saml:Conditions
    NotBefore="2009-06-24T11:47:34Z"
    NotOnOrAfter="2010-12-24T11:47:34Z">

...

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

...

worden.


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

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>

...

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

...

.113883.2.4.6.6:IIext:300

Authenticatie

<saml:AuthnStatement

   AuthnInstant="2009-06-24T11:47:34"

...

Uitgaande van de beveiligingsniveaus van GBZ, zorgverlener/medewerker en UZI-pas wordt het "urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI" of  "urn:oasis:names:tc:SAML:2.0:ac:classes:X509" beveiligingsniveau gehanteerd om het AORTA vertrouwensniveau midden voor zorgverleners weer te geven.

</saml:AuthnStatement>

Afsluiting authentication statement.

...

weer te geven.


</saml:AuthnStatement>

Afsluiting authentication statement.


Attributen

<saml:AttributeStatement>

...


</saml:AttributeStatement>

...

Algoritmes

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.

...

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).

...

4.3 en §5.4.4).


Opbouw

De headers

Eerst wordt het SAML inschrijftoken – het <saml:Assertion ...> element aangemaakt en gevuld met die elementen, zoals beschreven in paragraaf 2.4 Inhoud.

...


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

...

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.

...