Interfaces Autorisatie Server ZA
Metadata Interface
Feature | |
---|---|
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 | |
---|---|
Type | Service |
Versie | 1.3.0 |
Groep | Autorisatie |
Gepubliceerd |
|
Delta | Ondersteuning Mitz en Actualiteitsregister:
|
Use case |
Feature | Versie | Dependency | Aanbieder | Afnemer |
---|---|---|---|---|
1.3.0 | * | * | ||
1.3.0 | AORTA-ID HTTP Header | * | * | |
1.3.0 | * | - | ||
1.3.0 | * | * | ||
1.3.0 | 2 | 2 | ||
1.3.0 | 2 | 2 | ||
1.3.0 | 1.1 | 1.1 | ||
1.3.0 | 2.1 | 2.1 | ||
1.3.0 | * | - | ||
1.3.0 | 3 | - | ||
1.3.0 | 1 | - |
De AORTA Token Exchange Interface is gebaseerd op OAuth token exchange.
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.
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:
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 "~":
Voorbeelden scope:
|
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
®istration_token=<base64url-encoded SAML Assertion>
®istration_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 |
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:
|
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"
}
HTTP statuscodes
HTTP statuscodes die kunnen worden geretourneerd zijn:
Stap | Omschrijving | Uitkomst |
---|---|---|
1 | Het systeem ontvangt een verzoek en start de verwerking. | |
2 | Het systeem controleert of het ontvangen request voldoet aan de AORTA interface specificaties. | Ongeldig verzoek statuscode 400, error=invalid_request |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
3 | Het systeem controleert, indien niet kan worden gegarandeerd dat dit al is gedaan door de primaire actor, de geldigheid van de meegezonden, van toepassing zijnde, tokens:
| Ongeldig verzoek statuscode 400, error=invalid_request |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
4 | Het systeem controleert of m.b.v. het APR, of de Resource Client (GBx-applicatie) beschikt over de conformances en systeemrollen, die zijn vereist voor de beoogde interactie(s), en voor de meegezonden tokens. | Client niet gekwalificeerd voor één of meerdere interactie(s) statuscode 403, error=access_denied, error_description="Initiërende applicatie beschikt niet over de vereiste capabilities." |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
5 | Het systeem bepaalt, m.b.v. de MAP Interface welk van de gevraagde interacties, gegeven het gehanteerde betrouwbaarheidsniveau, zijn toegestaan conform het Medisch Autorisatie Protocol. | Géén van de interacties is toegestaan statuscode 403, error=access_denied |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
6 | Indien de beoogde interactie operation $get-aorta-data of een generieke v3-query betreft, die bestemd is voor de resource broker, dan genereert het systeem het vereiste AORTA access_token, en gaat verder naar de exit stap van de flow. Access_tokens mogen niet door het systeem worden opgeslagen. | |
7 | Het systeem bepaalt, voor interacties die in de AORTA interactietabel zijn gemarkeerd als een pull-interactie, m.b.v. de Selectie en Determinatie Interface welke inperkende zoekparameters eventueel moeten worden opgenomen in de scope van het uit te geven AORTA access_token. Voor interacties die zijn gemarkeerd als een push-interactie bepaalt het systeem a.d.h.v. de AORTA interactietabel (classifier attribuut) of er inperkende attributen zijn die moeten worden opgenomen in de scope van het access_token. | Combinatie van operation, contextcode en rolcode niet gevonden statuscode 400, error=invalid_request |
Classifier in interactietabel heeft andere waarde in SDS statuscode 500 | ||
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
8 | Indien de audience van het token exchange request een appID of URA bevat, dan bepaalt het systeem, m.b.v. de Routing Info Interface, welke interactie(s) door de betreffende bestemming kunnen worden ontvangen. | Géén appID gevonden statuscode 403, error=access_denied, error_description="Ontvangende applicatie beschikt niet over de vereiste capabilities." |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
9 | Indien de audience van het token exchange request een GBZ-applicatie (appID) bevat, en blijkens de scope van het token exchange request gegevens worden opgevraagd, dan toetst het systeem of de betreffende patiënt toestemming heeft gegeven voor de gevraagde scope van autorisatie, zoals beschreven in "Toelichting controle toestemming patiënt". | Géén van de interacties is toegestaan statuscode 403, error=access_denied |
Fout bij bepalen status van toestemming statuscode 500 | ||
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
10 | Indien het request een interactie betreft m.b.t. een AuditEvent, en blijkens de audience van het token exchange request is bestemd voor de resource broker zelf (rb_log), dan voert het systeem de controles uit, zoals beschreven in "specifieke autorisatieregels RB-logging". Eventuele inperkingen die van toepassing zijn worden uitgedrukt in de scope van het uit te geven AORTA access_token. | Géén van de interacties is toegestaan statuscode 403, error=access_denied |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
11 | Indien het request een interactie betreft die deel uitmaakt van de Actualiteitsregister Interface, en blijkens de audience van het token exchange request is bestemd voor de resource broker zelf (rb_vwi), dan voert het systeem de controles uit, zoals beschreven in "specifieke autorisatieregels ACT/VWI". Eventuele inperkingen die van toepassing zijn worden uitgedrukt in de scope van het uit te geven AORTA access_token. | Géén van de interacties is toegestaan statuscode 403, error=access_denied |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
12 | Indien het request een interactie betreft m.b.t. een Subscription, en blijkens de audience van het token exchange request is bestemd voor het Abonnementenregister (rb_abr), dan voert het systeem de controles uit, zoals beschreven in "specifieke autorisatieregels Abonnementenregister". Eventuele inperkingen die van toepassing zijn worden uitgedrukt in de scope van het uit te geven AORTA access_token. | Géén van de interacties is toegestaan statuscode 403, error=access_denied |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
13 | Het systeem genereert het vereiste AORTA access_token, conform de hoogste versie die wordt ondersteund door de audience. Access_tokens mogen niet door het systeem worden opgeslagen. Voor de vulling van de scope van het access_token wordt gebruik gemaakt van classificerende attributen, zoals benoemd in de AORTA interactietabel, en indien van toepassing ook van te hanteren zoekparameters die zijn verkregen uit de SDS. Zie ook de “Toelichting vulling smart-on-fhir scope en _vrb_ter_scope in het AORTA access_token”. | |
14 <exit> | Het systeem retourneert een response naar de primaire actor. |
AORTA Token Expansion
Feature | |
---|---|
Type | Service |
Versie | 2.1.0 |
Groep | Autorisatie |
Gepubliceerd |
|
Delta | Ondersteuning Mitz en Actualiteitsregister:
|
Use case |
Feature | Versie | Dependency | Aanbieder | Afnemer |
---|---|---|---|---|
2.1.0 | * | * | ||
2.1.0 | AORTA-ID HTTP Header | * | * | |
2.1.0 | * | - | ||
2.1.0 | 3 | - | ||
2.1.0 | 1 | - |
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.
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.
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:
|
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.
HTTP statuscodes
HTTP statuscodes die kunnen worden geretourneerd zijn:
Stap | Omschrijving | Uitkomst |
---|---|---|
1 | Het systeem ontvangt een verzoek en start de verwerking. | |
2 | Het systeem controleert of het ontvangen request voldoet aan de AORTA interface specificaties. | Ongeldig verzoek statuscode 400, error=invalid_request |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
3 | Het systeem controleert de geldigheid van het meegezonden AORTA access_token, zoals omschreven in de sectie "Toetsing AORTA access_token". | |
4 | Het systeem bepaalt, m.b.v. de Selectie en Determinatie Interface welke interacties dienen te worden geïnitieerd (zie ook de toelichting “Gebruik van de SDS bij het bepalen van de interacties”). | Combinatie van operation, contextcode en rolcode niet gevonden statuscode 400, error=invalid_request |
Classifier in interactietabel heeft andere waarde in SDS statuscode 500 | ||
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
5 | Bij ongeadresseerde operation (géén aud claim aanwezig in het ontvangen assertion): Het systeem bepaalt, voor iedere te initiëren interactie, m.b.v. feature getSourceInfo, welke GBZ-applicaties beschikken over gegevens die bij de betreffende interactie dienen te worden opgeleverd. De GBZ-applicatie van de opvrager zelf (de Resource Client), wordt hier, indien aanwezig in de set, uit weggehaald. Het appID van de Resource Client is opgenomen in de _vrb_client_id claim van het ontvangen AORTA access_token. | Doelsystemen kunnen niet worden bepaald statuscode 500 |
Géén geschikt doelsysteem gevonden statuscode 400, error=invalid_target | ||
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
6 | Het systeem bepaalt, voor alle GBZ-applicaties die een interactie moeten ontvangen, danwel voor de gehele URA (bij gerichte operation aan een URA), m.b.v. de Routing Info Interface, welke interactie(s) precies kunnen en moeten worden geïnitieerd. Deze info wordt gevraagd voor alle van SDS ontvangen FHIR- of v3-interacties. D.w.z., wanneer het te converteren access_token is uitgegeven voor een FHIR $get-aorta-data, dan wordt routing info gevraagd voor FHIR-interacties. Wanneer het te converteren access_token is uitgegeven voor een hybride generieke query, dan wordt routing info gevraagd voor v3-interacties. | Interactie(s) kunnen niet worden bepaald statuscode 500 |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
7 | Het systeem genereert het vereiste AORTA access_token, conform de hoogste versie die wordt ondersteund door de audience. Access_tokens mogen niet door het systeem worden opgeslagen. Voor de vulling van de scope van het access_token wordt gebruik gemaakt van classificerende attributen, zoals benoemd in de AORTA interactietabel, en indien van toepassing ook van te hanteren zoekparameters die zijn verkregen uit de SDS. Zie ook de “Toelichting vulling smart-on-fhir scope en _vrb_ter_scope in het AORTA access_token”. | |
8 <exit> | Het systeem retourneert een response naar de primaire actor. |
GetTokenRequest
Feature | |
---|---|
Type | Service |
Versie | 1.0.0 |
Groep | Autorisatie |
Gepubliceerd |
|
Delta | Initiële versie van feature. |
Use case |
Feature | Versie | Dependency | Aanbieder | Afnemer |
---|---|---|---|---|
1.0.0 | * | * | ||
1.0.0 | AORTA-ID HTTP Header | * | * | |
1.0.0 | * | - | ||
1.0.0 | 3 | - | ||
1.0.0 | 1 | - |
De GetTokenRequest Interface is gebaseerd op de AORTA Token Exchange Interface.
Een getTokenRequest wordt op de volgende wijze verzonden:
POST [base endpointadres]/getTokenRequest/v1
De HTTP headers die worden meegezonden bij het verzenden van een getTokenRequest zijn dezelfde als die worden meegezonden bij een tokenExchangeRequest.
Een getTokenRequest bevat de volgende attributen:
Parameter | Cardinaliteit | Toelichting |
grant_type | 1..1 | Vaste waarde "urn:ietf:params:oauth:grant-type:token-exchange" |
client_id | 1..1 | Het appID van de client (GBx-applicatie) die een interactie wil initiëren. Formaat van een applicatie-id:
|
audience | 1..1 | Waarde is "<appID van GBZ-applicatie>". Formaat van een applicatie-id:
|
requested_token_type | 1..1 | Vaste waarde "urn:ietf:params:oauth:token-type:jwt". |
subject_token | 1..1 | Zie onderstaande tabel. |
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. |
scope | 1..1 | Zie scope bij tokenExchangeRequest. |
Het subject_token wordt niet digitaal ondertekend, en bevat de volgende elementen en attributen:
Element/@Attribuut | Cardinaliteit | Toelichting |
---|---|---|
@ID | 1..1 | Unieke identificatie van de Assertion |
@Version | 1..1 | “2.0” |
@IssueInstant | 1..1 | Tijdstip van uitgifte van de Assertion. |
Issuer | 1..1 | De Issuer wordt gevuld met de URA uit het UZI-servercertificaat van de Resource Client. |
Issuer.@Format | 1..1 | "urn:oasis:names:tc:SAML:2.0:nameid-format:entity" |
Conditions.@NotBefore | 1..1 | Het tijdstip van uitgifte van de Assertion. |
Conditions.@NotOnOrAfter | 1..1 | @NotBefore plus 60 seconden. |
AttributeStatement | 1..1 | Zie onderstaande tabel. |
@Name | Cardinaliteit | Toelichting |
"patientIdentifier" | 1..1 | Het BSN van de patient. Formaat van een burgerservicenummer:
|
“contextCodeSystem” | 0..1 | Verplicht aanwezig wanneer “contextCode” aanwezig is. Vaste waarde: "2.16.840.1.113883.2.4.3.111.15.1" |
“contextCode” | 0..1 | De contextcode die aanduidt binnen welke (zorg)toepassing de interactie word geïnitieerd, bijv. "BGZ", of "MEDGEG". Aanwezig indien van toepassing bij de interactie. |
Een getTokenResponse bevat dezelfde attributen als een tokenExchangeResponse. De error responses en HTTP statuscodes die worden geretourneerd zijn eveneens gelijk aan die bij een tokenExchangeResponse.