Versions Compared

Key

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

In dit hoofdstuk wordt de inhoud van het SAML mandaattoken besproken die bij mandatering en de berichtauthenticatie met behulp van de UZI-pas wordt gebruikt. Het SAML mandaattoken bevat informatie over de mandaatgever in relatie tot de gemandateerde zorgmedewerker. Het SAML mandaattoken is een op XML gebaseerd SAML assertion en heeft tot doel de assertions (bewijs van een bewering) over te brengen tussen partijen.

...

Het SAML mandaattoken is een afgegeven SAML assertion die gebruikt wordt bij mandatering en berichtauthenticatie met behulp van de UZI-pas voor het landelijk EPDbinnen AORTA. Er wordt gebruik gemaakt van SAML v2.0 [SAML Core].

...

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 registratie van het mandaat.

Issuer

1

De zorgverlener die het mandaat afgeeft.

@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 die het mandaat verleent (de mandaterende). De handtekening dient geplaatst te zijn met behulp van het handtekening-certificaat op de pas.

Subject

1

Bevat Bevat de Organisatie (URA) waarbinnen het mandaat geldig is.

BaseID

0

Niet gebruiken

Let op: Indien dit veld gevuld wordt bij het uitlezen van de UZI pas, dan zal dit veld in het geval van gastgebruik niet de juiste URA bevatten. Er wordt aanbevolen dit veld met de URA uit het gebruikte servercertificaat te vullen.

BaseID

0

Niet gebruiken

NameID

1

Bevat de URA

EncryptedID

0

Niet gebruiken

SubjectConfirmation

1

Moet aanwezig zijn

@Method

1

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

SubjectConfirmationData

0

Niet gebruiken

@Recipient

0

Niet gebruiken

@NotOnOrAfter

0

Niet gebruiken

@InResponseTo

0

Niet gebruiken

@NotBefore

0

Niet gebruiken

@Address

0

Niet gebruiken

KeyInfo

0

Niet gebruiken

Conditions

1

Moet aanwezig zijn

@NotBefore

1

Moet aanwezig zijn.

@NotOnOrAfter

1

Moet aanwezig zijn.

Condition

0

Niet gebruiken

AudienceRestriction

1

Moet aanwezig zijn

Audience

1

urn:IIroot:2.16.840.1.113883.2.4.6.6:IIext:1 (is de ZIM)

AudienceRestriction

1

Moet aanwezig zijn

Audience

1

urn:IIroot:2.16.840.1.113883.2.4.6.6:IIext:<AppId> (is de verzendende GBZ-applicatie)

ProxyRestriction

0

Niet gebruiken

Advice

0

Niet gebruiken

AuthnStatement

0

Niet gebruiken

AttributeStatement

1

Moet aanwezig zijn

Attribute

1

Moet aanwezig zijn

@Name

1

Vaste waarde: "autorisatieregel/context"

AttributeValue

1

URI waar de autorisatieregel/context gevonden kan worden waarbinnen het mandaat gegeven wordt.

...

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

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


Code Block
<saml:Assertion ... xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

 

Het SAML mandaattoken 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.3.1 Uniekheid beschreven.



Anchor
Uniekheid
Uniekheid

...

Uniekheid


Code Block
ID="token_2.16.528.1.1007.3.3.1234567.1_0123456789"

...



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 assertion mag meerdere malen als token gebruikt worden. 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)[1] 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.


[1] Zie het RfC4122 opgesteld door het IETF: A Universally Unique Identifier (UUID) URN Namespace

...

Het attribuut IssueInstant is een tijdsmoment van uitgifte van de SAML assertion, in andere woorden: het tijdstip van ondertekening. 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
Afzender
Afzender
Afzender


Code Block
<saml:Issuer>

...



  123456789:01.015

...



</saml:Issuer>



De Issuer verwijst naar de UZI van de zorgverlener/medewerker die het mandaat registreert (de mandaatgever) in combinatie met de rolcode van diezelfde zorgverlener/medewerker gescheiden door een dubbele punt (:).

Anchor
Onderwerp
Onderwerp
Onderwerp


Code Block
<saml:Subject>

...



  <saml:NameID>

...



     urn:IIroot:2.16.528.1.1007.3.3:IIext:12345678

...



  </saml:NameID>

...



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

...



  </saml:SubjectConfirmation>

...



</saml:Subject>



De Subject verwijst naar de organisatie waarbinnen het mandaat geldig is.

...

Vervolgens moet de SubjectConfirmation nog toegevoegd worden:


Code Block
  <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches">

...



  </saml:SubjectConfirmation>


Anchor
Geldigheid
Geldigheid
Geldigheid


Code Block
<saml:Conditions

...



 NotBefore="2009-06-24T11:47:34Z"

...



 NotOnOrAfter="2009-09-24T11:47:34Z">


 

Het attribuut NotBefore is de tijd waarop de SAML assertion geldig wordt. Dit hoeft niet de tijd te zijn waarop het mandaat is aangemaakt. Het is mogelijk NotBefore in de toekomst te zetten. NotBefore moet altijd op of na de aanvang van de geldigheidsdatum van het certificaat (waarmee het mandaat is getekend) liggen.

...


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


De subelementen OneTimeUse en ProxyRestriction worden niet gebruikt binnen het <Conditions> element bij het mandaattoken.

Anchor
Ontvanger
Ontvanger
Ontvanger

In de AudienceRestriction wordt beschreven aan wie de SAML assertion is gericht. Aangezien het mandaattoken bedoeld is voor gebruik door een verzendende applicatie en bedoeld is om door de ZIM begrepen te worden, worden er binnen de AudienceRestriction twee Audience elementen opgenomen, één voor de ZIM en één voor de verzendende GBZ-applicatie.

...

De volledige AudienceRestriction wordt dan:



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>

...



  <!-- Root en extensie van de Applicatie -->

...



  <saml:Audience>urn:IIroot: 2.16.840.1.113883.2.4.6.6:IIext:300</saml:Audience>

...



</saml:AudienceRestriction>


Anchor
Attributen
Attributen
Attributen

Code Block
<saml:AttributeStatement>


Het volgende attribuut betreft aanvullende gegevens met betrekking tot het mandaat. Er mogen geen andere attributen opgenomen worden in het AttributeStatement dan hier beschreven is.



Code Block
<saml:Attribute Name="autorisatieregel/context">

...



  <saml:

...

AttributeValue>https://goedbeheerdziekenhuis/autorisatieregels/medicatiecontext/v2</saml:

...

AttributeValue>

</saml:Attribute>



Via de URI dient de lokale autorisatieregel en/of de context opgehaald te kunnen worden waarbinnen het mandaat is uitgegeven. In het voorbeeld is voor een URL gekozen.

...

Tenslotte wordt het attributen statement blok afgesloten met


Code Block
</saml:AttributeStatement>

Algoritmes

Om de integriteit en onweerlegbaarheid van het SAML mandaattoken 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 de publieke sleutel van het UZI handtekening-certificaat van de verzender onomstotelijk vaststellen dat de getekende SAML assertion ondertekend is met de privé sleutel behorend bij het gebruikte UZI handtekening-certificaat van de UZI-pas van de zorgverlener.

...

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



 Image Modified

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


Opbouw

De headers

Eerst wordt het SAML mandaattoken – het <saml:Assertion ...> element aangemaakt en gevuld met die elementen, zoals beschreven in paragraaf 2.3 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.3 Inhoud ...

...



</saml:Assertion>



Het XML Signature blok is onderdeel van het SAML mandaattoken. Het XML Signature blok komt na het <saml:Issuer> element.



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>

...



   123456789:01.015

...



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

...



        <X509IssuerSerial>

...



          <X509IssuerName>CN=De Auteur CA,O=Nictiz,C=NL</X509IssuerName>

...



          <X509SerialNumber>359724...41160195</X509SerialNumber>

...



        </X509IssuerSerial>

...



      </ds:X509Data>

...



    </ds:KeyInfo>

...



  </ds:Signature>  ...

...



  ... Zie paragraaf 2.3 Inhoud ...

...



</saml:Assertion>


Indien de Signature aangemaakt wordt mogen de strings (saml:Assertion en SignedInfo) inhoudelijk niet meer gewijzigd worden. 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.

...