Skip to main content
Skip table of contents

Interfaces Autorisatie Server ZA

Metadata Interface

Feature

getMetadataZA

Type

Service

Versie

1.0.0

Groep

Autorisatie

Gepubliceerd

Delta

Initiële versie van feature.

Use case

-

Feature

Versie

Dependency

Aanbieder

Afnemer

Metadata

AOF.AS-I.MTD.200.v1

De metadata van de Autorisatie Server kan, conform RFC 8414, worden opgehaald op een well-known URL die kan worden geconstrueerd m.b.v. de  <iss> claim uit het token (zie ook section-3.1 van RFC8414). De Authorization Server Metadata Response bevat de volgende attributen. Dit betekent dat bij een iss die gelijk is aan: https://FQDN/some-path-extension, de metadata kan worden verkregen bij: https://FQDN/.well-known/oauth-authorization-server/some-path-extension.

De metadata omvat de volgende attributen:

  • issuer;

  • token_endpoint;

  • jwks_uri;

  • response_types_supported;

  • signed_metadata.

De response die wordt geretourneerd bevat daarnaast de volgende headers:

Cache-Control: must-revalidate, max-age=<max-age-metadata>
Pragma: no-cache

Een client mag verkregen metadata conform de Cache-Control header directives, zoals beschreven in RFC 7234, cachen.

De waarde van max-age-metadata is configureerbaar in de autorisatie server. Initiële waarde is 14400 seconden (4 uur).

JWKS

AOF.AS-I.MTD.300.v1

De public key waarmee de digitale handtekening kan worden gecontroleerd wordt als een JWK beschikbaar gesteld. De URL waarop de JWK Set kan worden opgevraagd (jwks_uri) maakt deel uit van de AS metadata response. Iedere JSON Web Key (JWK) in de set, die beschikbaar wordt gesteld op de jwks_uri, bevat een kid parameter. De juiste JWK in de JWK Set wordt gevonden o.b.v. de waarde van het kid attribuut in de header van de ontvangen JWT.

De response die wordt geretourneerd na een HTTP GET op de jwks_uri bevat naast de JWK Set de volgende headers:

Cache-Control: must-revalidate, max-age=<max-age-jwks>
Pragma: no-cache

Een client mag verkregen JWK's conform de Cache-Control header directives, zoals beschreven in RFC 7234, cachen.

De waarde van max-age-jwks is configureerbaar in de autorisatie server. Initiële waarde is 14400 seconden (4 uur).

De JWK bevat de volgende attributen, waar de definitie van de attributen kan worden gevonden in RFC 7517 en RFC 7518:

  • "kty":"RSA"

  • "alg":"RS256"

  • "use":"sig"

  • "kid":"<the identifier of the key-pair used to sign this JWT>"

  • "x5c":"<de van toepassing zijnde keten van PKIX certificaten>"

  • "n":"<the modulus value for the RSA public key>"

  • "e":"<the exponent value for the RSA public key>"

AORTA Token Interface

AORTA Token Exchange

Feature

AORTA Token Exchange

Type

Service

Versie

1.2.2

Groep

Autorisatie

Gepubliceerd

Delta

<patch - 1.2.2>

Bij pull interacties die zijn gericht aan een VZVZ component, dient de SDS niet te worden geraadpleegd voor eventuele aanvullende autorisatie restricties. Wanneer de SDS wel wordt geraadpleegd, dan moet rekening worden gehouden met het al dan niet overridable zijn van een attribuut blijkens de SDS.

<patch - 1.2.3> Aanpassingen t.b.v. abonneren:

  • Bij token exchange request voor aanmaken, wijzigen en verwijderen is de contextcode vereist die aanduidt over welke gegevens het abonnement gaat.

  • Bij token exchange request voor zoeken naar abonnementen wordt gebruik gemaakt van de generieke contextcode “OPVABR”, zodat abonnementen die worden opgevraagd niet worden ingeperkt tot een specifieke dataset.

  • Bij token exchange request voor aanmaken/wijzigen van een abonnement door een zorgverlener, een andere vulling van scope hanteren

    • patient/Subscription.c?SourceSystem=urn:oid:2.16.840.1.113883.2.4.6.6.<appID>

    • patient/Subscription.u?SourceSystem=urn:oid:2.16.840.1.113883.2.4.6.6.<appID>

Use case

AOF.UC.ASZA.100.v1

De AORTA Token Exchange Interface is gebaseerd op OAuth token exchange.

AOF.AS-I.ATE.100.v2

Het AORTA Token Exchange endpoint is slechts benaderbaar voor de ZA-in component van de resource broker en voor GBx-applicaties die deel uitmaken van AORTA.

Een tokenExchangeRequest wordt op de volgende wijze verzonden:

POST [base endpointadres]/tokenx/v1

Bij het verzenden van een tokenExchangeRequest dienen de volgende HTTP headers te worden meegezonden:

Feature

AORTA-ID HTTP Header

Type

Subfeature

Versie

1.0.0

Groep

HTTP Headers

Gepubliceerd

Delta

Initiële versie van feature.

AORTA-ID: initialRequestID=<UUID conform RFC4122>; requestID=<UUID conform RFC4122>

Het initialRequestID attribuut bevat het ID van het allereerste request in de hele keten en dient te worden opgenomen in de logbestanden van alle partijen in de keten, zodat bij foutopsporing de verschillende logbestanden aan elkaar kunnen worden gerelateerd.

Het requestID is voor iedere request message uniek. In requests wordt deze gegenereerd door de client. Ook het requestID dient te worden opgenomen in de verschillende logbestanden, zodat altijd duidelijk is op welk bericht een log entry van toepassing is.

AOF.AS-I.ATE.200.v6

Een tokenExchangeRequest bevat de volgende attributen:

Parameter

Cardinaliteit

Toelichting

grant_type

1..1

Vaste waarde "urn:ietf:params:oauth:grant-type:token-exchange"

client_id

0..1

Het appID van de client die een FHIR-interactie wil initiëren. Hoeft slechts te worden meegezonden, wanneer het niet is opgenomen in het actor_token. Vooralsnog daarom slechts van toepassing voor interacties vanuit een GBP.

Formaat: "urn:oid:2.16.840.1.113883.2.4.6.6.<applicatie-id>".

audience

0..1

Bij geadresseerde interacties tussen GBZ'en:

Waarde is "<appID van GBZ-applicatie>".

Wanneer de client een FHIR-update of een FHIR-read interactie wil uitvoeren, dan is het juiste appID opgenomen in de base-URL van de betreffende resource instance, zoals eerder ontvangen. Instance-level interacties, zoals een read en een update dienen altijd te worden gericht aan één GBZ-applicatie, en nooit aan een URA.

Wanneer de client een ander soortige FHIR-interactie wil uitvoeren, dan zijn er een aantal mogelijkheden:

  1. De client bepaalt zelf, m.b.v. de systeemrollen en conformances, zoals gevonden in ZORG-AB, en m.b.v. de transformatie server metadata, welk(e) GBZ-applicatie(s), eventueel na translatie, de betreffende interactie kan/kunnen ontvangen.

  2. De client vraagt de Adressering Server, welk(e) GBZ-applicatie(s), eventueel na translatie, de betreffende interactie kan/kunnen ontvangen.

Bij interacties tussen een GBZ-applicatie en een Resource Broker component:

Waarde is "<role van betreffende Resource Broker component>".

Bij geadresseerde FHIR $get-aorta-data operation:

Waarde is "<URA van het GBZ>" of “<appID van GBZ-applicatie>”.

Bij ongeadresseerde/gespreide FHIR $get-aorta-data operation:

Niet aanwezig.

Formaat van een appID: "urn:oid:2.16.840.1.113883.2.4.6.6.<applicatie-id>".

Formaat van een URA: "urn:oid:2.16.528.1.1007.3.3.<URA>".

Formaat van een role: "urn:oid:2.16.840.1.113883.2.4.3.111.8.<role-id>"

requested_token_type 

1..1

Vaste waarde "urn:ietf:params:oauth:token-type:jwt".

subject_token

1..1

A security token that represents the identity of the party on behalf of whom the request is being made. Typically, the subject of this token will be the subject of the security token issued in response to the request.

Wanneer geen actor_token aanwezig is, dan is het subject_token een AORTA SAML transactietoken, een SAML PKIo Authenticatietoken, een SAML DigiD token.

Wanneer wel een actor_token aanwezig is, dan is het subject token een AORTA SAML mandaattoken.

subject_token_type  

1..1

Type aanduiding van het subject_token. Vaste waarde "urn:ietf:params:oauth:token-type:saml2". Geeft aan dat het token een base64url-encoded SAML 2.0 Assertion is.

actor_token

0..1

A security token that represents the identity of the acting party. Typically, this will be the party that is authorized to use the requested security token and act on behalf of the subject.

Een actor_token is slechts aanwezig wanneer de acting party een andere is dan het subject.

Een actor_token is altijd een AORTA SAML transactietoken. Het subject_token is in dat geval dan een AORTA SAML mandaattoken.

actor_token_type

0..1

Type aanduiding van het actor_token. Vaste waarde "urn:ietf:params:oauth:token-type:saml2". Geeft aan dat het token een base64url-encoded SAML 2.0 Assertion is.

registration_token

0..1

Het registration_token is een AORTA SAML inschrijftoken.

registration_token_type

0..1

Type aanduiding van het registration_token. Vaste waarde "urn:ietf:params:oauth:token-type:saml2". Geeft aan dat het token een base64url-encoded SAML 2.0 Assertion is.

consent_token

0..1

Het consent_token is een AORTA SAML consent_token.

consent_token_type

0..1

Type aanduiding van het consent_token. Vaste waarde "urn:ietf:params:oauth:token-type:saml2". Geeft aan dat het token een base64url-encoded SAML 2.0 Assertion is.

scope

1..1

Een string met daarin de gevraagde scope van autorisatie, die bestaat uit de volgende opeenvolgende delen, van elkaar gescheiden door een "~":

  • Een door spaties van elkaar gescheiden set van AORTA interaction-id's, bijvoorbeeld "search:eAfspraak-Appointment:2", "operation:$get-aorta-data:1" of "GQZG_IN000001NL“;

  • De contextCode, waarbinnen de interacties plaatsvinden, bijvoorbeeld "aorta.contextcode.BGZ" - niet aanwezig wanneer een v3-pushbericht wordt verzonden;

  • Een aanduiding van de situatie waarin de interactie plaatsvindt, "normaal" of "nood". Vooralsnog is deze parameter gevuld met vaste waarde "normaal".

Voorbeelden scope:

  • Opvragen van specifieke resources bij een GBZ-applicatie: "search:eAfspraak-Appointment:2 search:zib-LivingSituation:2~aorta.contextcode.BGZ~normaal".

  • Verzenden van een v3-pushbericht via Resource Broker v3-in (dus t.b.v. een v3-client): “PVMV_IN932000NL03~~normaal“.

  • Verzenden van een FHIR pushbericht via Resource Broker ZA-in (dus t.b.v. een FHIR-client): “transaction:mp-MedicationPrescription-Bundle:1~aorta.contextcode.MEDPRESC~normaal“.

  • Registreren van een nieuwe abonnement: “<INTERACTIE-ID>~aorta.contextcode.MEDGEGTOT~normaal“.

  • Wijzigen van een abonnement: “<INTERACTIE-ID>~aorta.contextcode.MEDGEGTOT~normaal“.

  • Beëindigen van een abonnement: “<INTERACTIE-ID>~aorta.contextcode.MEDGEGTOT~normaal“.

  • Opvragen van abonnementen: “<INTERACTIE-ID>~aorta.contextcode.OPVABR~normaal“.

Mogelijke combinaties van subject_token, actor_token, registration_token en consent_token zijn:

Initiator

subject_token

actor_token

registration_token

consent_token

GBZ

AORTA SAML transactie_token, gesigned met een UZI-servercertificaat

-

-

-

AORTA SAML transactie_token, gesigned met een UZI-pas (zorgverlenerspas)

-

-

Slechts aanwezig wanneer de initiator een "notified-pull" uitvoert (dus een pull n.a.v. een notificatie).

AORTA SAML mandaat_token, gesigned met een UZI-pas (zorgverlenerpas)

AORTA SAML transactie_token, gesigned met een UZI-pas (zorgverlenerspas of medewerkerpas op naam)

-

Slechts aanwezig wanneer de initiator een "notified-pull" uitvoert (dus een pull n.a.v. een notificatie).

AORTA SAML mandaat_token, gesigned met een UZI-pas (zorgverlenerpas)

AORTA SAML transactie_token, gesigned met een UZI-servercertificaat

-

Aanwezig.

Deze combinatie van tokens is slechts mogelijk bij een pull n.a.v. een notificatie.

AORTA SAML mandaat_token, gesigned met een UZI-pas (zorgverlenerpas)

AORTA SAML transactie_token, gesigned met een UZI-servercertificaat

AORTA SAML inschrijf_token, gesigned met een UZI-pas (zorgverlenerpas)

-

GBK

SAML PKIo Authenticatietoken, gesigned met een PKIo-pas

-

-

-

GBP

SAML DigiD token

-

-

-

Voorbeeld van een tokenExchangeRequest:

POST [base]/tokenx/v1
Content-Type: application/x-www-form-urlencoded
AORTA-ID: initialRequestID=<UUID conform RFC4122>; requestID=<UUID conform RFC4122>

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&audience=urn%3Aoid%3A2.16.840.1.113883.2.4.6.6.352
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
&subject_token=<base64url-encoded SAML Assertion>
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Asaml2
&actor_token=<base64url-encoded SAML Assertion>
&actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Asaml2
&registration_token=<base64url-encoded SAML Assertion>
&registration_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Asaml2
&consent_token=<base64url-encoded SAML Assertion>
&consent_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Asaml2
&scope=search%3AeAfspraak-Appointment%3A2%20search%3Azib-LivingSituation%3A2~aorta.contextcode.BGZ~normaal

Een tokenExchangeResponse bevat de volgende attributen:

Parameter

Cardinaliteit

Toelichting

access_token

1..1

Een JWT-based AORTA access_token. Er wordt één token uitgegeven met een audience element voor ieder te bevragen xIS van deze zorgaanbieder, die om kan gaan met het requested_token_type.

issued_token_type 

1..1

Type aanduiding van de representatievorm van het uitgegeven access_token. Vaste waarde "urn:ietf:params:oauth:token-type:jwt".

token_type 

1..1

Vaste waarde "Bearer".

expires_in 

1..1

Geldigheid in seconden van het uitgegeven AORTA access_token. Deze bedraagt 20 seconden.

scope 

1..1

Dezelfde string, zoals ontvangen in het token exchange response, maar met daarin slechts de onderdelen die daadwerkelijk zijn toegekend.

Wanneer een transformatie is vereist voor een interactie, dan wordt dit in de geretourneerde scope aangegeven door het interactie-id uit te breiden met "/<transformation-id>".

Voorbeelden van een geretourneerde scope:

  • Opvragen van specifieke resources bij een GBZ-applicatie: "search:eAfspraak-Appointment:2 search:zib-LivingSituation:2~aorta.contextcode.BGZ~normaal".

  • Opvragen van resource bij een GBZ-applicatie, waarvoor transformatie is vereist: "search:eAfspraak-Appointment:2/3~aorta.contextcode.AFSPR~normaal".

  • Uitvoeren van operation $get-aorta-data: "operation:$get-aorta-data:1~aorta.contextcode.BGZ~normaal".

Te hanteren error responses zijn eveneens beschreven in RFC 8693.

Voorbeeld van een tokenExchangeResponse:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{
    "access_token": "2YotnFZFEjr1zCsicMWpAA",
    "issued_token_type": "urn:ietf:params:oauth:token-type:jwt",
    "token_type": "Bearer",
    "expires_in": 20,
    "scope": "search:eAfspraak-Appointment:2/3~aorta.contextcode.AFSPR~normaal"
}

AORTA Token Expansion

Feature

AORTA Token Expansion

Type

Service

Versie

2.0.1

Groep

Autorisatie

Gepubliceerd

Delta

Toevoeging geparameteriseerde $get-aorta-data en geparameteriseerde hybride generieke query.

<patch - 2.0.1> Bug fix:

Bij een token expansion dient de Autorisatie Server slechts bronnen te zoeken o.b.v. interacties die hetzelfde protocol hebben als het protocol van de interactie waarvoor de expansion wordt uitgevoerd. Hetzelfde geldt voor het verkrijgen van routing info bij de Adressering Server.

Use case

AOF.UC.ASZA.200.v1

De AORTA Token Expansion Interface is gebaseerd op het Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, en specifiek hierbinnen op het JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants.

AOF.AS-I.ATR.100.v2

Het AORTA Token Expansion endpoint is slechts benaderbaar voor de VnC component van de resource broker.

Een tokenExpansionRequest wordt op de volgende wijze verzonden:

POST [base endpointadres]/token/v2

Bij het verzenden van een tokenExpansionRequest dienen de volgende HTTP headers te worden meegezonden:

Feature

AORTA-ID HTTP Header

Type

Subfeature

Versie

1.0.0

Groep

HTTP Headers

Gepubliceerd

Delta

Initiële versie van feature.

AORTA-ID: initialRequestID=<UUID conform RFC4122>; requestID=<UUID conform RFC4122>

Het initialRequestID attribuut bevat het ID van het allereerste request in de hele keten en dient te worden opgenomen in de logbestanden van alle partijen in de keten, zodat bij foutopsporing de verschillende logbestanden aan elkaar kunnen worden gerelateerd.

Het requestID is voor iedere request message uniek. In requests wordt deze gegenereerd door de client. Ook het requestID dient te worden opgenomen in de verschillende logbestanden, zodat altijd duidelijk is op welk bericht een log entry van toepassing is.

AOF.AS-I.ATR.200.v2

Een tokenExpansionRequest bevat de volgende attributen (zie ook sectie 2.1 van RFC 7523):

Parameter

Cardinaliteit

Toelichting

grant_type

1..1

Vaste waarde "urn:ietf:params:oauth:grant-type:jwt-bearer".

assertion

1..1

Een JWT-based AORTA access_token. Dit token is enkel bedoeld voor de Resource Broker, en niet voor achterliggende GBx-servers.

scope

1..1

Het scope attribuut bestaat uit een clinical data scope conform SMART-on-FHIR 2.0, waarbij ook fine-grained constraints kunnen worden opgenomen in de vorm van search-parameters, waarmee eventuele parameters die zijn meegezonden in de $get-aorta-data operation of the hybride generieke v3-query worden doorgegeven.

Voorbeelden:

  • "patient$get-aorta-data?context=MEDGEG&destination=urn:oid:2.16.528.1.1007.3.3.<URA>"

  • "patient$get-aorta-data?context=MEDGEG&destination=urn:oid:2.16.840.1.113883.2.4.6.6.<app-id>"

  • "patient$get-aorta-data?context=MEDGEG&effective-time=ge2010-01-01&effective-time=le2011-12-31"

  • "patient$get-aorta-data?context=MEDGEG&therapy-identifier=http://example.nl/fhir/NamingSystem/pharmaceuticaltreatment|<id>"

  • "patient$get-aorta-data?context=MEDGEG&classifier=urn:oid:2.16.840.1.113883.2.4.4.8|<id>"

  • "patient$get-aorta-data?context=MEDGEG&instance-identifier=http://example.nl/fhir/NamingSystem/MedicationRequest|<id>"

De autorisatieserver retourneert, in de vorm van een JSON-array, een set van één of meerdere token responses.

Een token response bevat de volgende attributen (zie ook sectie 5 van RFC 6749) :

Parameter

Cardinaliteit

Toelichting

access_token

1..1

Een JWT-based AORTA access_token. Dit token is bedoeld voor een achterliggende GBx-server.

token_type 

1..1

Vaste waarde "Bearer".

expires_in 

1..1

Geldigheid in seconden van het uitgegeven AORTA access_token. Deze bedraagt 20 seconden.

scope 

1..1

Analoog aan de scope van een AORTA Token Exchange Response. De scope van een response (en van het afgegeven access_token) betreft de FHIR-interacties die deel uitmaken van de FHIR-operation/contextcode (en die ook daadwerkelijk worden ondersteund door de betreffende GBx-server).

Te hanteren error responses zijn eveneens beschreven in sectie 5 van RFC 6749.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.