Use Cases Autorisatie Server GTK
Overzicht Autorisatie Server GTK
Onderstaande figuur toont een overzicht van de interfaces, services en functies van de Autorisatie Server GTK component.
Autorisatie Server GTK is verantwoordelijk voor:
Het uitgeven van client_assertions en assertions die kunnen worden gebruikt om access_tokens aan te vragen bij andere GTK’s;
Het ontvangen van token requests van andere GTK’s.
De services zijn toegankelijk via een geboden interface en worden beschreven in de vorm van use cases. Een service wordt altijd vervult middels één of meerdere applicatiefuncties, bijvoorbeeld TWIIN Autorisatie Server.
Uitgeven TWIIN Assertions
Primaire actor | Resource Broker GTK |
|---|---|
Systeem | TWIIN Assertion Issuer |
Secundaire actor | - |
Code | |
Realiseert Feature |
Pre-condities
De primaire actor is aangesloten op het systeem. |
Het systeem is slechts benaderbaar voor
|
Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen. |
Triggers
De primaire actor stuurt een request in
Main flow
Stap | Omschrijving | Uitkomst |
|---|---|---|
1 | Het systeem ontvangt een verzoek en start de verwerking. | |
2 | Het systeem toetst of het verzoek voldoet aan de interface specificatie. | Ongeldig verzoek statuscode 400 Bad 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 ontvangen sourceToken:
| Ongeldig token statuscode 401 Unauthorized |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
4 | Het systeem genereert, o.b.v. van de gegevens in het ontvangen sourceToken, een AORTA-TWIIN Client Authentication Assertion (client_assertion) en een AORTA-TWIIN Authorization Grant Assertion (assertion). Let op! Indien het verzoek een authzBase bevat, dan betreft een verzoek om direct na ontvangst van een notification-Task, assertions te generen t.b.v. het verkrijgen van een workflow-Task, en dient
| |
5 | Het systeem bepaalt op de volgende wijze of een scope attribuut moet worden opgenomen in de response: Indien de scope van het ontvangen AORTA access_token de string
bevat, dan moet als scope in de response worden opgenomen:
In overige gevallen wordt geen scope attribuut opgenomen in de response. In deze situaties dient het AORTA access_token een _vrb._vrb_authz_base claim te bevatten. Het systeem toetst dit. | AORTA access_token mist vereiste authorization_base statuscode 400 Bad Request |
6 <exit> | Het systeem retourneert een response naar de primaire actor. | Verwerking succesvol statuscode 200 OK |
Post-condities
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:
== Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:
Aanvullend daarop heeft het systeem van het ontvangen request de volgende attributen gelogd:
|
Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:
== Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:
Aanvullend daarop heeft het systeem van de geretourneerde response de volgende attributen gelogd:
|
Uitgeven AORTA access_token
Primaire actor | Extern GTK |
|---|---|
Systeem | TWIIN Autorisatie Server |
Secundaire actor | ZORG-AB, Autorisatie Server ZA |
Code | |
Realiseert Feature |
Pre-condities
De primaire actor is aangesloten op het TWIIN netwerk. |
Het systeem is slechts benaderbaar voor
|
Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen. |
Triggers
De primaire actor stuurt een request in
Main flow
Stap | Omschrijving | Uitkomst |
|---|---|---|
1 | Het systeem ontvangt een verzoek en start de verwerking. | |
2 | Het systeem toetst of het verzoek voldoet aan de interface specificatie. Het systeem toetst of de volgende attributen aanwezig zijn en ook een juiste waarde bevatten:
Het systeem toetst of de volgende attributen aanwezig zijn:
Een scope is verplicht wanneer géén assertion is opgenomen, die een autorization_base bevat. Een eventueel aanwezige authorization_base moet een SAML AORTA consent_token zijn. Wanneer wel een consent_token aanwezig is in de ontvangen assertion, maar geen scope werd ontvangen, dan wordt de scope van het request (door AS ZA) bepaald o.b.v. de contextcode in het consent_token. De volgende attributen worden inhoudelijk later getoetst, op het moment dat een AORTA access_token wordt gevraagd aan Autorisatie Server ZA:
| 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 de ontvangen client_assertion, d.w.z.
| Ongeldige client statuscode 400 Bad Request, error=invalid_client |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
4 | Het systeem controleert de geldigheid van de ontvangen assertion, d.w.z.
| Ongeldige grant statuscode 400 Bad Request, error=invalid_grant |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
5 | Het systeem controleert de geldigheid van een eventueel ontvangen client_id, en indien van toepassing, of deze overeenkomt met de sub in de client_assertion. | 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. | ||
6 | Het systeem toetst, m.b.v. ZORG-AB, of de primaire actor binnen het TWIIN afsprakenstelsel is gekwalificeerd, om namens de URA in de assertion, interacties te initieren zoals aangeduid door de scope van het request. Vooralsnog moet de gehele scope worden ondersteund. NB. omdat ZORG-AB hiervoor niet tijdig geschikt zal zijn, wordt deze check vooralsnog niet uitgevoerd. Zie ook: registratie in ZORG-AB. | Primaire actor niet gekwalificeerd 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 toetst, m.b.v. ZORG-AB, of de beoogde AORTA destination (GBZ-applicatie) de interacties, zoals aangeduid door de scope van het request, via Twiin wenst te ontvangen. Vooralsnog moet de gehele scope worden ondersteund. NB. omdat ZORG-AB hiervoor niet tijdig geschikt zal zijn, wordt deze check vooralsnog niet uitgevoerd. Zie ook: registratie in ZORG-AB. | Destination wil interactie niet via Twiin ontvangen statuscode 403 Forbidden, error=access_denied, error_description="AORTA-deelnemer kan/wil interactie niet ontvangen via Twiin." |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
8 | Indien géén authorization_base is ontvangen, dan vertaalt het systeem de ontvangen SMART-on-FHIR formaat scope naar het scope formaat, zoals vereist bij gebruik van Feature GetTokenRequest. Het systeem gebruikt hiervoor de AORTA interactietabel. De ontvangen scope mag in deze situatie slechts gaan over het verzenden of het wijzigen van een notificatie, op de wijze zoals gespecificeerd in: Omdat het om één of meerdere push-interacties gaat, hoeft geen contextcode te worden doorgegeven, en mag als situatie “normaal” worden gehanteerd. | Kan scope niet vertalen statuscode 400 Bad Request, error=invalid_request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
Pull-interactie ontvangen zonder authorization_base statuscode 400 Bad Request, error=invalid_request | ||
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
9 | Indien de scope ruimer is dan slechts het verzenden of het wijzigen van een notificatie, dan toetst het systeem of de assertion een BSN bevat. | BSN van patient ontbreekt statuscode 400 Bad Request, error=invalid_request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
10 | Het systeem gebruikt Feature GetTokenRequest om een AORTA access_token te verkrijgen. Hierbij worden de volgende attributen gebruikt:
| |
11 <exit> | Het systeem retourneert een response naar de primaire actor. | Alle mogelijke uitkomsten van GetTokenRequest. |
Post-condities
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:
== Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:
|
Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:
== Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:
|