In dit hoofdstuk wordt de inhoud van het SAML inschrijftoken besproken. Het SAML inschrijftoken bevat de, binnnen binnen een zorgorganisatie, gevalideerde BSN en is ondertekend door een zorgverlener /of 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
...
De assertion heeft de volgende zorgverlener of medewerker of m.b.v. het identiteitscertificaat van de medewerker die uitgegeven is door ZORG-ID. 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 plaatsgevonden of waar het inschrijftoken wordt verlengd of waar 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. Bij verlenging van het inschrijftoken wordt alleen gebruik gemaakt van het identiteitscertificaat van de medewerker die uitgegeven is door ZORG-ID. |
Subject | 1 | BSN van de patient patiënt 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 of zorgverlener pas 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 of het personeelsnummer indien het scantoken gegenereerd is door ZORG-ID. |
Attribute | 0..1 | Alleen aanwezig indien het een nieuw 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 |
...
| Attribute | 0. |
...
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/.1 | Alleen aanwezig indien het een inschrijftoken wordt verlengd op basis van een eerdere inschrijftoken aangemaakt op basis van een UZI-pas van een zorgverlener of medewerker of op basis van een eerdere scantoken op basis van het identiteitscertificaat van de uitvoerende medewerker uit ZORG-ID. |
| @Name | 0..1 | Vaste waarde “Verlengingstoken” |
| AttributeValue | 0..1 | Het originele inschrijftoken op basis van een UZI-pas of het eerdere Scantoken op basis van het identiteitscertificaat van de uitvoerende zorgverlener/medewerker uit ZORG-ID dat verlengd gaat worden, wordt Base64 geencodeerd. |
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 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. |
...
| 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.
\\ |
...
Inhoud
De volgende paragrafen beschrijven de verschillende kenmerken en beveiligingsgerelateerde gegevens die het SAML inschrijftoken onderscheiden, zoals in [IH tokens generiek] beschreven is.
| Code Block |
|---|
<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 | ||||
|---|---|---|---|---|
|
| 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 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).
...
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 |
|---|
...
|
...
|
...
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:"<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 |
|---|
...
|
...
|
...
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
1) aan Aan de balie door:
- Een face to face controle van de patient en diens Wettelijk Identiteits Document (WID)
- Een controle van de geldigheid van het WID bij SBV-Z
- Een controle van de correctheid van het BSN bij SBV-Z
2) door Door inlezen van de chip uit het WID waarbij:
- De echtheid van het WID wordt gecontroleerd
- De BSN wordt uitgelezen uit de chip of, bij paspoorten uitgegeven na 1 augustus 2021, de BSN QR code wordt gelezen.
3) Het subject en de daarbij behorende BSN overnemen uit het oorspronkelijke inschrijftoken dat verlengd gaat worden.
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 |
|---|
...
|
...
|
| 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 inschrijftoken is getekend) liggen.
...
Het attribuut NotOnOrAfter is de tijd waarop de SAML assertion vervalt. NotOnOrAfter mag na het verstrijken van de geldigheid van het certifcaat certificaat (waarmee het inschrijftoken is getekend) liggen.
...
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.
...
Het inperken van bepaalde partijen (AudienceRestriction) waarvoor de assertion bedoeld is wordt beschreven in paragraaf 2.4.5 Ontvanger.
...
<saml:AudienceRestriction>
.4.5 Ontvanger.
| Anchor | ||||
|---|---|---|---|---|
|
| 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.
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
...
.6.6:IIext:300
| Anchor | ||||
|---|---|---|---|---|
|
| Code Block |
|---|
<saml:AuthnStatement AuthnInstant AuthnInstant="2009-06-24T11:47:34" SessionIndex SessionIndex="token_2.16.528.1.1007.3.3.1234567.1_0123456789"> \\ \\ Het |
Het subject,
...
de
...
gevalideerde
...
BSN,
...
in
...
de
...
SAML
...
assertion
...
is
...
geauthentiseerd door
...
middel
...
van
...
een
...
authenticatiemiddel
...
van
...
de
...
uitvoerende
...
zorgverlener/medewerker.
...
Als de zorgverlener/medewerker
...
de
...
UZI-pas
...
heeft
...
gebruikt
...
wordt
...
de
...
AuthContextClassRef
...
SmartcardPKI:
...
| Code Block |
|---|
<saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI</saml:AuthnContextClassRef> </saml:AuthnContext> \\ \\ Als de |
Als de zorgverlener/medewerker
...
ZORG-ID
...
heeft
...
gebruikt
...
wordt
...
de
...
AuthContextClassRef
...
X509:
...
| Code Block |
|---|
<saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:X509</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 "{_} |
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
...
"
...
of
...
"
...
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
...
"
...
beveiligingsniveau
...
gehanteerd
...
om
...
het
...
AORTA vertrouwensniveau midden voor zorgverleners weer te geven.
| Code Block |
|---|
</saml:AuthnStatement> |
Afsluiting authentication statement.
| Anchor | ||||
|---|---|---|---|---|
|
| 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.
Uitvoerder
| Code Block |
|---|
<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.
Indien het scantoken is gegenereerd door Zorg-ID, dan kan dit attribuut ook het personeelsnummer uitgegeven door de zorgorganisatie bevatten. In dat geval dient het personeelsnummer voorafgegaan te worden door een OID die deze personeelsnummering aanduidt, Dit zal over het algemeen een OID zijn die begint met de OID van de zorgorganisatie.
Bijvoorbeeld:
<saml:AttributeValue>2.16.840.1.113883.2.4.3.65.1.2:1234567</saml:AttributeValue>
In dit voorbeeld zijn de volgende waarden te vinden:
2.16.840.1.113883.2.4.3.65: Elkerliek ziekenhuis
1.2: personeelsnummers
1234567 personeelsnummer Medewerker X
Scantoken
<saml:Attribute Name="Scantoken">
<saml:AttributeValue ook de Common Name (CN) van het identiteitscertificaat waarmee het token is ondertekend bevatten.
Bijvoorbeeld:
| Code Block |
|---|
<saml:AttributeValue>Jan Test:91000001</saml:AttributeValue> |
In dit voorbeeld zijn de volgende waarden te vinden:
Jan Test: Voornaam Achternaam
91000001: Uniek nummer`. Start van 91000000 en hoger.
Scantoken
| Code Block |
|---|
<saml:Attribute Name="Scantoken">
<saml:AttributeValue xsi:type="base64Binary">
Hier het scantoken base64 geëncodeerd.
</saml:AttributeValue>
</saml:Attribute> |
Het attribuut Scantoken bevat het Scantoken Base64 geëncodeerd. Voor de opbouw van het Scantoken wordt verwezen naar [AORTA_Auth_IH_Scantoken]. Dit attribuut dient alleen aanwezig (en gevuld) te zijn als het gehele inschrijftoken ondertekend is met het identiteitscertificaat van ZORG-ID.
Verlengingstoken
| Code Block |
|---|
<saml:Attribute Name="Verlengingstoken"> <saml:AttributeValue xsi:type="base64Binary"> |
...
Hier het |
...
originele inschrijftoken base64 geëncodeerd. |
...
...
</saml:AttributeValue> |
...
</saml:Attribute> |
Het attribuut Scantoken bevat het Scantoken Verlengingstoken bevat het originele Inschrijftoken obv UZI-pas of het Scantoken op basis van het identiteitscertificaat van de uitvoerende medewerker uit ZORG-ID, Base64 geëncodeerd. Voor de opbouw van het Scantoken wordt verwezen naar [AORTA_Auth_IH_Scantoken]. Dit Het attribuut Verleningstoken dient alleen aanwezig (en gevuld) te zijn als het gehele inschrijftoken ondertekend is met het identiteitscertificaat van ZORG-ID.
...
attributeStatement blok
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="Uitvoerder"> |
...
<saml:AttributeValue>123456789</saml:AttributeValue> |
...
</saml:Attribute> |
Tenslotte wordt het attributen statement blok afgesloten met
| Code Block |
|---|
</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.
...
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
...
- -256 digest.
...
| 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“exc-c14n transformatie" transformatie” (zie ook [SAML Core] §5.4.3 en §5.4.4). | ]]></ac:plain-text-body></ac:structured-macro> |
...
4). |
| Anchor | ||||
|---|---|---|---|---|
|
De headers
Eerst wordt het SAML inschrijftoken – 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 inschrijftoken. 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.
Lange Base 64 waarden zijn afgekort. Wederom kan dit als strings worden behandeld, waarbij drie waarden vervangen moeten worden.
Deze drie waarden worden ingevuld:
- Neem het SignedInfo blok op.
- Neem de SignatureValue op.
- Neem certificaatgegevens in het KeyInfo blok op, in de vorm van een verwijzing (X509IssuerSerial).
...
| 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.
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.
| Code Block |
|---|
<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> |