...
In lijn met keuzes op de Proces- en Informatielaag, treden deze servers op namens alle eventuele achterliggende systemen in het Zorgaanbiedersdomein, zoals xIS'en. Die achterliggende complexiteit is een black box. Het is mogelijk dat een individuele xIS optreedt voor beide servers, maar dan moeten ook alle met deze rollen verbonden verantwoordelijkheden zijn ingevuld, zowel de direct verbonden verantwoordelijkheden (op de Applicatielaag) als de indirect verbonden verantwoordelijkheden (op de lagen erboven en eronder).
1. | Uitgever:
| |||||
2. | Bron:
| |||||
3. | Zorggebruiker gebruikt twee geautomatiseerde rollen voor toegang tot de functionaliteit van PGO Server en Authorization Server: PGO Presenter voor de presentatie van de functionaliteit aan Zorggebruiker en PGO User Agent voor het aanspreken van PGO Server en Authorization Server. | |||||
4. | MedMij Beheer ontsluit ten behoeve van alle betrokkenen een geautomatiseerde dienst, hier genoemd: MedMij Registratie. | |||||
5. | Ten behoeve van het authenticeren van Zorggebruiker, zal de betrokken Authorization Server, in de rol van Authentication Client, gebruikmaken van de Authentication Service van een Authenticatie Provider ZA. | |||||
6. | Ten behoeve van het autoriseren van PGO Server voor toegang tot Resource Server, in het kader van UCI Verzamelen en UCI Delen, respectievelijk tot Subscription Server in het kader van UCI Abonneren, zullen de betrokken PGO User Agent, PGO Server, Authorization Server en Resource Server, respectievelijk Subscription Server, gebruik maken van OAuth 2.0, waarbij als grant type gebruik wordt gemaakt van Authorization Code en waarbij:
| |||||
7. | Als MedMij-verkeer is gedefinieerd: al het gegevensverkeer in het kader van enige use case-implementatie op deze laag of op de Netwerk-laag, onmiddellijk tussen twee verschillende van de vier volgende soorten rollen, namelijk:
met dien verstande dat:
| |||||
8. | Al het MedMij-verkeer, voor zover daarin de PGO User Agent:
|
Authorization Server, Resource Server en Subscription Server
...
Use cases en Gegevensdiensten
1a. | Bovengenoemde rollen implementeren de use case UC Verzamelen met de use case-implementatie UCI Verzamelen. Zij gebruiken hiertoe het betreffende stroomdiagram. De gehele procesgang wordt ononderbroken uitgevoerd. | |||||
1b. | Bovengenoemde rollen implementeren de use case UC Delen met de use case-implementatie UCI Delen. Zij gebruiken hiertoe het betreffende stroomdiagram. De gehele procesgang wordt ononderbroken uitgevoerd. | |||||
1c. | Voor zover de betreffende Uitgever, respectievelijk de betreffende Bron, UC Abonneren en UC Notificeren aanbieden, implementeren bovengenoemde rollen de UC Abonneren met de use case-implementatie UCI Abonneren en de UC Notificeren met de use case-implementatie UCI Notificeren. De gehele procesgang wordt ononderbroken uitgevoerd.
| |||||
2. | Als een Uitgever een zekere Gegevensdienst ontsluit ten behoeve van zijn Zorggebruikers en daartoe laat leveren door een Bron of Lezer, zullen de PGO Server van die Uitgever en de Authorization Server en Resource Server van die Bron, respectievelijk Lezer, daarvoor de bij de Gegevensdienst horende use case implementeren en de bij de Gegevensdienst horende Systeemrollen gebruiken, zoals deze in de Catalogus zijn opgenomen, en zich daarbij te conformeren aan de specificaties van die Systeemrollen zoals die zijn gepubliceerd op de plaats(en) waarnaar de Catalogus verwijst met Functionelespecificatieverwijzing en Technischespecificatieverwijzing.
|
Autorisatie en OAuth
3. | In de use case-implementaties UCI Verzamelen, UCI Delen en UCI Abonneren handelen PGO Server enerzijds en Authorization Server en Resource Server of Subscription Server anderzijds, hun onderlinge verkeer af conform de standaard OAuth 2.0.
| |||||
4. | Van de vier soorten authorization grants die OAuth 2.0 biedt, beperken de OAuth-rollen zich tot Authorization Code.
| |||||
5. | De OAuth Client en OAuth Resource Server zullen slechts tokens van het type Bearer Token uitwisselen, conform RFC6750.
| |||||
6 | De OAuth Client maakt alleen gebruik van één scope tegelijk. De OAuth Authorization Server genereert authorization codes en access tokens met een enkelvoudige scope die geheel vervat moet zijn in de Gegevensdienst waarom de OAuth Client heeft gevraagd.
| |||||
7. | De OAuth Authorization Server stelt van elke uitgegeven authorization code en elk uitgegeven access token de geldigheidsduur op exact 15 minuten (900 seconden). Zij geeft bovendien geen refresh tokens uit.
| |||||
8a. | De OAuth Authorization Server genereert authorization codes en access tokens zodanig, dat de kans op het raden ervan niet groter is dan 2-128 en de daarvoor gebruikte random number generators cryptografisch veilig zijn. | |||||
8b. | In de authorization codes en access tokens is het desgewenst toegestaan één of meer van de informatie-elementen uit de volgende limitatieve lijst op te nemen:
| |||||
8c. | Geen andere informatie dan de in verantwoordelijkheid 8b genoemde mag voorkomen in de authorization code of het acces token, ook niet versleuteld. Er mogen t.a.v. informatie-inhoud van het token verschillende keuzes gemaakt worden tussen authorization code en access token. De OAuth Client mag de inhoud van het token niet interpreteren. | |||||
8d. | Met betrekking tot zowel authorization codes als access tokens, draagt de OAuth Authorization Server die hen uitgeeft ervoor zorg, dat daarvan nooit twee dezelfde geldige in omloop zijn.
| |||||
8e. | Access tokens worden alleen uitgegeven na controle van de client_id, de opgegeven autorisatie code en de Common name van het in de TLS verbinding gebruikte certificaat. De controles worden uitgevoerd conform: |
|
| ||||||
9. | Het OAuth-client type van de OAuth Client is confidential.
|
Lijsten
10a. | MedMij Registratie en elke PGO Server implementeren de use case UC Opvragen ZAL met de use case-implementatie UCI Opvragen ZAL, door middel van het bepaalde inzake het ZAL interface op GNL-, OCL- en ZAL-interface. Zij gebruiken hiertoe het betreffende stroomdiagram. |
10b. | PGO Server betrekt minstens elke vijftien minuten (900 seconden) de meest recente ZAL-implementatie van MedMij Registratie. |
10c. | PGO Server valideert elke nieuw verkregen ZAL-implementatie tegen het XML-schema van de Zorgaanbiederslijst. Dit XML-schema is een technische implementatie van het MedMij-metamodel. |
11a. | MedMij Registratie, Authorization Server en Notification Client implementeren de use case UC Opvragen OCL met de use case-implementatie UCI Opvragen OCL, door middel van het bepaalde inzake het OCL interface op GNL-, OCL- en ZAL-interface. Zij gebruiken hiervoor het betreffende stroomdiagram. |
11b. | Authorization Server en Notification Client betrekken minstens elke vijftien minuten (900 seconden) de meest recente OCL-implementatie van MedMij Registratie. |
11c. | Authorization Server en Notification Client valideren elke nieuwe verkregen OCL-implementatie tegen het XML-schema van de OAuth Client List. Dit XML-schema is een technische implementatie van het MedMij-metamodel. |
12a. | MedMij Registratie, PGO Server en Authorization Server implementeren de use case UC Opvragen GNL met de use case-implementatie UCI Opvragen GNL, door middel van het bepaalde inzake het GNL interface op GNL-, OCL- en ZAL-interface. Zij gebruiken hiervoor het betreffende stroomdiagram. |
12b. | PGO Server en Authorization Server betrekken minstens elke vijftien minuten (900 seconden) de meest recente GNL-implementatie van MedMij Registratie. |
12c. | PGO Server en Authorization Server valideren elke nieuwe verkregen GNL-implementatie tegen het XML-schema van de GNL. Dit XML-schema is een technische implementatie van het MedMij-metamodel. |
Beveiliging
13. | In het gegevensverkeer voor UCI Verzamelen, UCI Delen, UCI Abonneren, UCI Notificeren, UCI Opvragen ZAL, UCI Opvragen OCL en UCI Opvragen GNL, maken betrokken rollen gebruik van de functies Versleuteling, Server Authentication en Server Authorization, volgens het bepaalde op de Netwerk-laag. | |||||||||||||||||||||||||||||||||||||||||||||||||||
14. | De OAuth Client en OAuth Authorization Server gebruiken voor al hun onderlinge verkeer PKIoverheid-certificaten, en wel servercertificaten, ten behoeve van de authenticatie van de andere server in een uitwisseling.
| |||||||||||||||||||||||||||||||||||||||||||||||||||
15. | De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC6819:
| |||||||||||||||||||||||||||||||||||||||||||||||||||
16. | De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC6819:
| |||||||||||||||||||||||||||||||||||||||||||||||||||
17. | De OAuth Authorization Server realiseert de volgende beveiligingsmaatregelen, conform RFC6819:
| |||||||||||||||||||||||||||||||||||||||||||||||||||
18. | OAuth Client, OAuth Authorization Server en OAuth Resource Server implementeren de op deze respectievelijke rollen toepasselijke beveiligingsmaatregelen, volgens paragaaf 5.3 van RFC6750.
|
Expand | ||
---|---|---|
| ||
Voor het opstellen van verantwoordelijkheden 15, 16 en 17 is gebruikgemaakt van RFC 6819 van IETF, dat een uitgebreide inventarisatie van die risico's bevat, inclusief een reeks van maatregelen per risico. Waar het risico van toepassing is op het gebruik van OAuth binnen MedMij, en de maatregelen passen binnen de MedMij-principes, zijn zij opgenomen in het afsprakenstelsel. Met betrekking tot het gestelde in sectie 3.1 van RFC 6819 kan gesteld worden dat MedMij uitgaat van:
In hoofdstuk 4 van RFC 6819 staat een uitgebreide lijst van beveiligingsrisico's. Niet van toepassing zijn, voor de deze release van het afsprakenstelsel:
Wel van toepassing zijn:
In relatie tot het MedMij Afsprakenstelsel vallen de maatregelen die getroffen moeten worden ter mitigatie van deze risico's uiteen in drie groepen:
|
Logging
19a. | Bij het loggen van verzonden resource requests neemt de OAuth Client ook het MedMij-Request-ID Header Field op in het logbestand. |
19b. | Bij het loggen van ontvangen resource requests neemt de OAuth Resource Server ook het MedMij-Request-ID Header Field op in het logbestand. |