Use Cases Autorisatie Server ZA

Resource Client (xIS), Resource Broker v3-in, Autorisatie Server GTK

AORTA Autorisatie Server

Resource Broker APR, MAP Server, SDS Server, Adressering Server

AOF.UC.ASZA.100.v8

AORTA Token Exchange, GetTokenRequest

De primaire actor is aangesloten op het systeem.

Het systeem is slechts benaderbaar voor

• GBx-applicaties die zijn aangesloten op het AORTA netwerk, OF

• componenten van VZVZ die zijn aangesloten via een intern netwerk of op het AORTA netwerk

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 Bad Request, error=invalid_request

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

3

Indien deze use case wordt doorlopen voor Feature AORTA Token Exchange, dan controleert het systeem, indien niet kan worden gegarandeerd dat dit al is gedaan door de primaire actor, de geldigheid van de meegezonden, van toepassing zijnde, tokens:

• subject_token

  • AORTA transactietoken, zoals omschreven in de sectie "Toetsing AORTA transactietoken".

  • DigiD token, zoals omschreven in de sectie "Toetsing DigiD Authenticatietoken".

  • PKIo Authenticatietoken, zoals omschreven in de sectie "Toetsing PKIo Authenticatietoken".

  • AORTA mandaattoken), zoals omschreven in de sectie "Toetsing AORTA mandaattoken".

• actor_token

  • AORTA transactietoken, zoals omschreven in de sectie "Toetsing AORTA transactietoken".

• registration_token (AORTA inschrijftoken), zoals omschreven in de sectie "Toetsing AORTA inschrijftoken".

• consent_token (AORTA consent_token), zoals omschreven in de sectie "Toetsing AORTA consent_token".

Ongeldig verzoek

statuscode 400 Bad Request, error=invalid_request

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

4

Indien geen scope parameter is ontvangen, maar wel een AORTA consent_token, dan bepaalt het systeem, m.b.v. Feature getInteractionContexts (SDS), o.b.v. de contextcode uit het consent_token, voor welke FHIR interactie(s) een AORTA access_token wordt gevraagd.

NB. omdat de scope van een consent_token vooralsnog altijd betrekking heeft op één of meerdere pull interacties, gericht aan een GBx-applicatie, en die moeten worden uitgevoerd op betrouwbaarheidsniveau Midden of hoger, kan ervan worden uitgegaan dat deze scope is opgenomen in de SDS.

Géén interactie(s) gevonden

statuscode 400 Bad Request, error=invalid_request

5

Indien de ontvangen scope parameter geen interacties bevat, maar wel een contextcode, dan bepaalt het systeem, m.b.v. Feature getInteractionContexts (SDS), o.b.v. de contextcode uit de scope parameter, voor welke FHIR interactie(s) een AORTA access_token wordt gevraagd.

Géén interactie(s) gevonden

statuscode 400 Bad Request, error=invalid_request

6

Het systeem controleert, m.b.v. Feature hasConformance (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.

Deze stap wordt niet uitgevoerd, indien de rol van Resource Client wordt vervuld door Resource Broker GTK.

Client niet gekwalificeerd voor één of meerdere interactie(s)

statuscode 403 Forbidden, error=access_denied, error_description="Initiërende applicatie beschikt niet over de vereiste capabilities."

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

7

Het systeem bepaalt, m.b.v. Feature checkRequest (MAP), welk van de gevraagde interacties, gegeven het gehanteerde betrouwbaarheidsniveau, zijn toegestaan conform het Medisch Autorisatie Protocol.

NB. deze stap is NIET van toepassing indien de scope parameter aangeeft dat het gaat om een request t.b.v. Mitz.

Géén van de interacties is toegestaan

statuscode 403, error=access_denied

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

8

Indien de beoogde interactie operation $get-aorta-data of een generieke v3-query betreft, dan genereert het systeem het vereiste AORTA access_token, en gaat het direct verder naar de exit stap van de flow.

Access_tokens mogen niet door het systeem worden opgeslagen.

9

Het systeem bepaalt, voor interacties die in de AORTA interactietabel zijn gemarkeerd als een pull-interactie, en die niet zijn gericht aan een VZVZ component of aan een externe component/dienst (bijv. Mitz), m.b.v. Feature getInteractionContexts (SDS), welke inperkende zoekparameters eventueel moeten worden opgenomen in de scope van het uit te geven AORTA access_token. Inperkende zoekparameters afkomstig uit de SDS worden slechts opgenomen in de scope van het access_token wanneer ze als niet-overridable zijn aangemerkt.

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. NB. classifier attributen voor pull-interacties zijn (naast in de interactietabel ook) als niet-overridable attributen opgenomen in de SDS, en hoeven daarom niet uit de interactietabel te worden gehaald.

NB. alle pull-interacties en bijbehorende contextcodes horen altijd opgenomen te zijn in de SDS, omdat het uitgangspunt is dat een specifieke opvraag in combinatie met een bepaalde contextcode ook moet kunnen worden getriggered middels een $get-aorta-data of generieke query met deze contextcode.

Voor interacties van het type transaction/batch is het in deze stap noodzakelijk om te kijken naar de individuele interacties die deel uitmaken van de transaction/batch.

Combinatie van operation, contextcode en rolcode niet gevonden

statuscode 400 Bad Request, error=invalid_request

Classifier in interactietabel heeft andere waarde in SDS

statuscode 500

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

10

Indien de destination van het request een appID OF een appID + een URA bevat:

Het systeem bepaalt m.b.v. Feature getRoutingInfo (Adressering Server), welke interactie(s) door de betreffende bestemming kunnen worden ontvangen.

Indien een URA en een appID worden meegegeven, en het appID behoort tot een GBZ-applicatie in AORTA (en dus niet tot Resource Broker GTK), dan vraagt het systeem slechts slechts Routing Info voor dit specifieke appID. Wanneer het appID behoort tot Resource Broker GTK, dan vraagt het systeem juist Routing Info voor de meegegeven URA.

Indien slechts een URA werd meegegeven dan wordt deze stap dus niet uitgevoerd, omdat in dat geval routingInfo zal worden gevraagd in een latere fase tijdens de token expansion.

Voor interacties van het type transaction/batch wordt in deze stap NIET gekeken naar de individuele interacties die deel uitmaken van de transaction/batch.

Géén appID gevonden

statuscode 403, error=access_denied, error_description="Ontvangende applicatie beschikt niet over de vereiste capabilities."

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

11

Indien de destination in het request een AORTA GBZ betreft (appID en/of URA), en blijkens de scope in het 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".

Voor interacties van het type transaction/batch is het in deze stap noodzakelijk om te kijken naar de individuele interacties die deel uitmaken van de transaction/batch.

Indien de destination een URA bevat + het appID van RB GTK, dan wordt deze stap niet uitgevoerd, omdat toestemming dan moet worden getoetst in het externe GTK.

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 response en gaat verder met de exit stap van de main flow.

12

Indien het request een interactie betreft m.b.t. een AuditEvent, en blijkens de destination van het 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 response en gaat verder met de exit stap van de main flow.

13

Indien het request een interactie betreft die deel uitmaakt van de Actualiteitsregister Interface, en blijkens de destination van het 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 response en gaat verder met de exit stap van de main flow.

14

Indien het request een interactie betreft m.b.t. een Subscription, en blijkens de destination van het 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 response en gaat verder met de exit stap van de main flow.

15

Indien het request een interactie betreft m.b.t. een Mitz toestemmingsregistratie, dan verkrijgt het systeem een Mitz access_token, op de wijze zoals beschreven in het Mitz afsprakenstelsel (Implementatiehandleiding ZNP).

Geen access_token verkregen

statuscode 500

16

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

Voor interacties van het type transaction/batch is het in deze stap noodzakelijk om te kijken naar de individuele interacties die deel uitmaken van de transaction/batch.

17

<exit>

Het systeem retourneert een response naar de primaire actor.

Het systeem heeft het verzoek op de juiste wijze verwerkt en heeft een daarbij passende response geretourneerd.

Het systeem heeft van het ontvangen request, de volgende attributen gelogd:

• datum en tijd van ontvangst

• request-id

• initial-request-id

• sender-id

  • role-id wanneer de sender van het request een VZVZ component is, en de aanroep niet via TLS geschiedt

  • common name wanneer de aanroep via TLS geschiedt

==

Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:

• datum en tijd van verzending

• request-id

• initial-request-id

• receiver-id

  • role-id wanneer de receiver van het request een VZVZ component is, en de aanroep niet via HTTP geschiedt

  • FQDN wanneer de aanroep via HTTP geschiedt

Aanvullend daarop heeft het systeem van het ontvangen request de volgende attributen gelogd:

• request.grant_type

• request.client_id

• request.audience

• request.requested_token_type

• request.subject_token_type

• ID van het subject_token

• request.actor_token_type

• ID van het actor_token

• request.registration_token_type

• ID van het registration_token

• request.consent_token_type

• ID van het consent_token

• request.scope

Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:

• datum en tijd van response

• request-id van het bijbehorende request

• initial-request-id van het bijbehorende request

• receiver-id

  • role-id wanneer de receiver van de response een VZVZ component is, en de aanroep niet via TLS geschiedt

  • common name wanneer de aanroep via TLS geschiedt

• HTTP statuscode en eventueel geretourneerde foutinformatie

==

Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:

• datum en tijd van response

• request-id van het bijbehorende request

• initial-request-id van het bijbehorende request

• sender-id

  • role-id wanneer de sender van de response een VZVZ component is, en de aanroep niet via TLS geschiedt

  • common name wanneer de aanroep via TLS geschiedt

• HTTP statuscode en eventueel geretourneerde foutinformatie

Aanvullend daarop heeft het systeem van de geretourneerde response de volgende attributen gelogd:

• response.issued_token_type 

• response.token_type 

• response.expires_in

• response.scope

• jti van het uitgeven AORTA access_token

• ver van het uitgeven AORTA access_token

Resource Broker VnC

AORTA Autorisatie Server

SDS Server, Lokalisatie Server, Adressering Server

AOF.UC.ASZA.200.v5

AORTA Token Expansion

De primaire actor is aangesloten op het systeem.

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 Bad Request, error=invalid_request

Het systeem genereert de vereiste response 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

Indien de beoogde interactie $get-aorta-data of een generieke v3-query betreft:

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

De beoogde interactie is opgenomen in de scope van het ontvangen AORTA access_token.

Combinatie van operation, contextcode en rolcode niet gevonden

statuscode 400 Bad Request, error=invalid_request

Classifier in interactietabel heeft andere waarde in SDS

statuscode 500

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

5

Indien het ontvangen token request één of meerdere FHIR-search interacties betreft (dit kan worden afgeleid van de scope en _vrb_ter_scope van het ingestuurde access_token), en de audience van het access_token slechts een URA bevat:

Het systeem hanteert de scope en de _vrb_ter_scope van het ontvangen AORTA access_token voor de vulling van uit te geven AORTA access_tokens. Eventueel vereiste inperkingen zijn hier al in aangebracht tijdens de token exchange.

6

Indien de beoogde interactie $get-aorta-data of een generieke v3-query betreft:

Het systeem bepaalt, voor iedere te initiëren interactie waarvan het protocol gelijk is aan het protocol van de interactie in de scope van het token request, m.b.v. feature getSourceInfo, welke GBZ-applicaties beschikken over gegevens die bij de betreffende interactie dienen te worden opgeleverd.

Wanneer getSourceInfo wordt uitgevoerd voor een specifieke source (URA of appID’s), dan kan het gebeuren dat de response geen dataCategories bevat. Dit heeft slechts gevolgen voor de attest claim van het uit te geven access_token, omdat geen toestemming kon worden vastgesteld. De betreffende appID('s) worden wel gewoon meegenomen in de volgende stap.

Wanneer getSourceInfo wordt uitgevoerd zonder een specifieke source mee te geven, dan zal de response ook voor iedere appID één of meerdere dataCategories bevatten.

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 response en gaat verder met de exit stap van de main flow.

7

Het systeem bepaalt, voor alle GBZ-applicaties die een interactie moeten ontvangen, danwel voor de gehele URA, m.b.v. Feature getRoutingInfo (Adressering Server), welke interactie(s) precies kunnen en moeten worden geïnitieerd. Er wordt hierbij slechts routing info gevraagd voor interacties waarvan het protocol gelijk is aan het protocol van de interactie in de scope van het token request.

Indien de beoogde interactie $get-aorta-data of een generieke v3-query betreft dan geldt dat 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.

Wanneer een GBZ-applicatie niet wordt gevonden door de Adressering Server, dan dient dit te worden gelogd. Indien geen enkele GBZ-applicatie wordt gevonden, dan is uitkomst “Geen destination gevonden” van toepassing.

Voor interacties van het type transaction/batch wordt in deze stap NIET gekeken naar de individuele interacties die deel uitmaken van de transaction/batch.

Interactie(s) kunnen niet worden bepaald

statuscode 500

Geen destination gevonden

statuscode 403, error=access_denied, error_description="Geen ontvangende applicatie gevonden."

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

8

Het systeem genereert de vereiste AORTA access_tokens, conform de hoogste versie die wordt ondersteund door de audience (één access_token per GBZ-applicatie).

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

Voor interacties van het type transaction/batch is het in deze stap noodzakelijk om te kijken naar de individuele interacties die deel uitmaken van de transaction/batch.

9

<exit>

Het systeem retourneert een response naar de primaire actor.

Het systeem heeft het verzoek op de juiste wijze verwerkt en heeft een daarbij passende response geretourneerd.

Het systeem heeft van het ontvangen request, de volgende attributen gelogd:

• datum en tijd van ontvangst

• request-id

• initial-request-id

• sender-id

  • role-id wanneer de sender van het request een VZVZ component is, en de aanroep niet via TLS geschiedt

  • common name wanneer de aanroep via TLS geschiedt

==

Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:

• datum en tijd van verzending

• request-id

• initial-request-id

• receiver-id

  • role-id wanneer de receiver van het request een VZVZ component is, en de aanroep niet via HTTP geschiedt

  • FQDN wanneer de aanroep via HTTP geschiedt

Aanvullend daarop heeft het systeem van het ontvangen request de volgende attributen gelogd:

• request.grant_type

• request.client_id

• request.audience

• request.requested_token_type

• request.subject_token_type

• ID van het subject_token

• request.actor_token_type

• ID van het actor_token

• request.registration_token_type

• ID van het registration_token

• request.consent_token_type

• ID van het consent_token

• request.scope

Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:

• datum en tijd van response

• request-id van het bijbehorende request

• initial-request-id van het bijbehorende request

• receiver-id

  • role-id wanneer de receiver van de response een VZVZ component is, en de aanroep niet via TLS geschiedt

  • common name wanneer de aanroep via TLS geschiedt

• HTTP statuscode en eventueel geretourneerde foutinformatie

==

Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:

• datum en tijd van response

• request-id van het bijbehorende request

• initial-request-id van het bijbehorende request

• sender-id

  • role-id wanneer de sender van de response een VZVZ component is, en de aanroep niet via TLS geschiedt

  • common name wanneer de aanroep via TLS geschiedt

• HTTP statuscode en eventueel geretourneerde foutinformatie

Aanvullend daarop heeft het systeem van de geretourneerde de volgende attributen gelogd:

• response.issued_token_type 

• response.token_type 

• response.expires_in

• response.scope

• jti van het uitgeven AORTA access_token

• ver van het uitgeven AORTA access_token

De Assertion correct is ondertekend, door de Signature te valideren met het gerefereerde authenticatie certificaat. Het gebruikte certificaat en de relevante certificaatketen te valideren op geldigheid, inclusief revocatie.

-

Er wordt voldaan aan alle controles, zoals omschreven in de sectie "Generieke toetsing AORTA SAML Assertions".

Een Assertion met eenzelfde ID attribuut niet al eerder is ontvangen.

De Issuer gelijk is aan de URA uit het servercertificaat van de TLS-Client waarmee wordt gecommuniceerd.

-

De Resource Client (zoals aangeduid in het applicationID Attribuut) onder de verantwoordelijkheid van de Issuer valt.

Indien Subject.NameID is gevuld: het transactietoken is getekend m.b.v. een UZI-zorgverlenerspas, of medewerker-pas-op-naam.

-

Het interactie-deel in de scope parameter van het token exchange request moet overeenkomen met:

• het InteractionId in het transactietoken, of met

• het interactie-deel in de Scope van het transactietoken.

Het contextcode-deel in scope parameter van het token exchange request moet gelijk zijn aan:

• de contextCode van transactietoken, of aan

• het contextcode-deel in de Scope van het transactietoken.

Het Mitz situatiecode-deel in scope parameter van het token exchange request moet gelijk zijn aan:

• het Mitz situatiecode-deel in de Scope van het transactietoken.