Overzicht van de architectuur
Infoexpand | ||
---|---|---|
| ||
Voor een overzicht over alle lagen van de architectuur, en voor een toelichting van de betekenis van de symbolen en lijntjes, zie de overzichtspagina. De afkorting:
|
Rollen
- Uitgever:
- biedt aan Zorggebruiker, in het kader van de toepasselijke Dienstverleningsovereenkomst, een geautomatiseerde rol ter gebruik, hier genoemd: PGO Server. Eén Uitgever biedt één of meerdere PGO Servers en elke PGO Server wordt door één Uitgever geboden.
- stelt, indien deze UC Notificeren aanbiedt, aan Zorgaanbieder een geautomatiseerde rol Notification Server ter beschikking, waarop de Zorgaanbieder Notificaties kan aanbieden. Eén zulke Uitgever één of meerdere Notification Servers en elke Notification Server wordt door één Uitgever geboden.
- Bron:
- biedt, en Lezer biedt, een geautomatiseerde dienst, voor het namens Zorgaanbieders uitwisselen van gezondheidsinformatie met PGO Server, bestaande uit: Authorization Server en Resource Server. Eén Bron en/of Lezer biedt één of meer combinaties van één Authorization Server en één Resource Server en elke combinatie van één Authorization Server en één Resource Server wordt door één Bron en/of Lezer geboden.
- biedt, indien deze UC Abonneren aanbiedt, een geautomatiseerde dienst voor het namens Zorgaanbieders aangaan van Abonnementen, bestaande uit Authorization Server en Subscription Server. Elke zulke Bron biedt één of meer combinaties van één Authorization Server en één Subscription Server en elke combinatie van één Authorization Server en één Subscription Server wordt door één Bron geboden.
- biedt, indien deze UC Notificeren aanbiedt, een geautomatiseerde rol voor het namens Zorgaanbieders plaatsen van Notificaties, genaamd Notification Client. Elke zulke Bron biedt één of meer Notification Clients en elke Notification Client wordt door één Bron geboden.
- 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.
- MedMij Beheer ontsluit ten behoeve van alle betrokkenen een geautomatiseerde dienst, hier genoemd: MedMij Registratie.
- 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.
- 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:
- de rol van OAuth User Agent wordt verzorgd door de PGO User Agent;
- de rol van OAuth Client wordt verzorgd door de PGO Server;
- de rol van OAuth Resource Server wordt verzorgd door de Resource Server, in het geval van UCI Verzamelen en UCI Delen, en door de Subscription Server in het geval van UCI Abonneren;
- de rol van OAuth Authorization Server wordt verzorgd door de Authorization Server.
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:
- ten eerste PGO Server of Notification Server,
- ten tweede PGO User Agent,
- ten derde Authorization Server, Resource Server, Subscription Server of Notification Client, en
- ten vierde MedMij Registratie,
- in deze rollen telkens begrepen zijn de door hen eventueel verzorgde respectievelijke Autorisatie-rollen,
- van deze rollen telkens uitgesloten zijn de door hen eventueel verzorgde Authenticatie-rollen, en
- in deze rollen, met betrekking tot de use case-implementaties op de Netwerk-laag, telkens inbegrepen zijn de Netwerk-rollen waarop zij functioneren.
Al het MedMij-verkeer, voor zover daarin de PGO User Agent:
- betrokken is, heet frontchannel-verkeer;
- niet betrokken is, vormt het backchannel-verkeer.
Info | ||
---|---|---|
| ||
Hier worden de rollen van de Processen-en-Informatie-laag vertaald naar rollen op applicatieniveau. Voor de algemene uitgangspunten inzake de getalsverhoudingen tussen de rollen, zie de pagina Architectuur en technische specificaties. In het persoonsdomein zijn drie rollen onderscheiden: de PGO Presenter, PGO User Agent en de PGO Server. Dat is nodig om de verbinding te kunnen leggen met de rollen volgens OAuth. PGO Presenter en PGO User Agent zijn alle front-end-rollen voor de PGO Server, en kunnen bijvoorbeeld allebei in een browser zijn geïmplementeerd, maar voor een goede binding aan de OAuth- en Authentication-rollen en voor een goede beveiligingsmaatregelen is het nodig deze twee rollen te scheiden. Zoals ook elders in het MedMij Afsprakenstelsel gaat het hier om rollen, om setjes verantwoordelijkheden dus, niet om implementatiecomponenten. In het Zorgaanbiedersdomein is zo'n scheiding niet nodig. Waar een Persoon zelf operationeel betrokken wordt in het informatieverkeer — namelijk om zich te laten authenticeren, en het verkeer te laten autoriseren — laat de Zorgaanbieder zich operationeel geheel vertegenwoordigen door zijn Dienstverlener en diens Authorization Server en Resource Server. Ook al zal in veel gevallen de gezondheidsinformatie uiteindelijk uit een achterliggend systeem worden betrokken, voor het MedMij Afsprakenstelsel is dat geen kwestie. Het is voldoende om bij de Authorization Server en Resource Server de eindverantwoordelijkheid neer te leggen (black box). 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). De keuze, in OAuth, voor de grant type Authorization Code past bij de typische software-architectuur die in MedMij in het Persoonsdomein wordt aangetroffen: toegang tot een PGO-dienst via componenten die niet onder controle van de OAuth Client vallen en als betrekkelijk onveilig moeten worden gezien. Op deze laag onderscheiden we bij deze toegang twee rollen: de rol PGO Presenter die zorgt voor de presentatie van de functionaliteit aan de Zorggebruiker, en de rol PGO User Agent die zorgt voor het aanspreken van de PGO Server en de Authorization Server. Het is de rol PGO User Agent die verbonden wordt met de rollen OAuth User Agent en Authentication User Agent. De PGO User Agent spreekt uiteindelijk dus ook de Authentication Service aan. |
...
title | Authorization Server, Resource Server en Subscription Server |
---|
De rollen Authorization Server en respectievelijk Resource Server (in UCI Verzamelen en UCI Delen) of Subscription Server (in UCI Abonneren) werken in het MedMij-afsprakenstelsel samen in eenzelfde ononderbroken sessie. Hun onderlinge relatie is een proceskoppeling. Dat wil zeggen, zij worden georkestreerd onder de hoede van één procesgang. Rollen in het MedMij Afsprakenstelsel zijn echter groepjes verantwoordelijkheden, geen implementatiecomponenten. Het is daarmee aan de Dienstverlener zorgaanbieder om in zijn implementatie, en business model, keuzes te maken over het scheiden of juist combineren van deze twee rollen. Als de rollen gescheiden zijn is het bovendien goed mogelijk om één Authorization Server of Subscription Server te laten samenwerken met meerdere Resource Servers en om één Resource Server zaken te laten doen met meerdere Authorization Servers of Subscription Servers. Steeds echter zullen zij samen het gedrag moeten vertonen dat wordt geëist door het MedMij Afsprakenstelsel. Overigens maakt ook de OAuth-specificatie gewag van deze implementatievrijheid.
Omdat de sessiecoördinatie in het Zorgaanbiederdomein zich over het scheidsvlak tussen Authorization Server en Resource Server of Subscription Server uitstrekt, moet er in geval van gescheiden implementatie van Authorization Server en Resource Server of Subscription Server een interface worden gerealiseerd waarin die sessiecoördinatie in stand blijft. Bovendien moet, als de relatie tussen Authorization Server en Resource Server of Subscription Server niet één-op-één is, ervoor worden gezorgd dat de juiste twee elkaar vinden bij de communicatie over een specifiek access token.
Ondanks deze implementatievrijheid hebben de verantwoordelijkheden in het MedMij Afsprakenstelsel invloed op de implementatie-architectuur in het Zorgaanbiedersdomein. Met name vereist de adressering dat er voor één combinatie van Zorgaanbieder, Gegevensdienst, Interfaceversie (en Systeemrol) maar één authorization endpoint en één token endpoint (en één resource endpoint of subscription endpoint) kan zijn. Bovendien voorkomen beperkingen op de informatie-inhoud van authorization codes en access tokens dat het interface tussen Authorization Server en Resource Server of Subscription Server via het Persoonsdomein wordt gerealiseerd. Op enkele uitzonderingen na is dat interface een interne aangelegenheid van het Zorgaanbiedersdomein. Daarmee worden zowel principes P1 en P7 gediend, alsook dataminimalisatie, en dus de privacy. De belangrijkste uitzondering is dat de authorization code en het access token desgewenst een identificatie mogen bevatten van de service die het heeft uitgegeven. Daarmee kan de (voorziene) acceptant van de authorization code of het access token de Authorization Server of Subscription Server vinden waar de validatie van de authorization code of het access token moet plaatsvinden.
...
Het is denkbaar dat een community van dienstverleners in het Zorgaanbiedersdomein tot een afsprakenstelsel komt, aanpalend aan en voldoend aan het MedMij Afsprakenstelsel, waarin de interne architectuur van het Zorgaanbiedersdomein aan de orde is. Naast bovenbedoelde scheiding zouden daarin bijvoorbeeld ook architectuurkeuzes over de beschikbaarheids- en ontvankelijkheidstoets kunnen worden opgenomen.
Info | ||
---|---|---|
| ||
Het is van belang om een heldere scheiding te maken tussen autorisatie en authenticatie in het MedMij Afsprakenstelsel. Niet alleen zijn het verschillende functionaliteiten, authenticatie voor vaststelling van identiteit en autorisatie voor het beheren van toegangsrechten, de bijbehorende rollen kunnen in het MedMij Afsprakenstelsel niet zomaar worden gecombineerd. De Authorization Server heeft de rol om, namens de Zorgaanbieder, op verzoek van de Persoon, autorisaties uit te delen aan de PGO Server. Om dat betrouwbaar te kunnen doen, en om aan een wettelijke verplichting van de Zorgaanbieder invulling te geven, schakelt de Authorization Server de (externe) Authentication Service in. Dat betekent echter niet dat de Authorization Server op haar beurt identiteitsdiensten gaat verlenen aan de PGO Server, door bijvoorbeeld een aan de BSN gekoppelde identiteit mee te geven met het acces token dat ze uitdeelt. Dat zou oneigenlijke verbreding zijn van haar authenticatierol, die begrensd zou moeten blijven tot de verantwoordelijkheden jegens de Zorgaanbieder en zich niet moet uitstrekken tot het bedienen van de PGO Server. Bovendien zou het een centrum van Persoons-identiteit creëren in het MedMij-landschap die, gezien de regiedoelstellingen van MedMij, bij voorkeur niet in het Zorgaanbiedersdomein ligt, maar in het Persoonsdomein, en daarbinnen bij voorkeur zo dicht mogelijk bij de Persoon zelf. Daarom vindt er op het koppelvlak tussen PGO Server en Authorization Server geen uitwisseling van Persoons-identiteiten plaats, niet met bijvoorbeeld de standaard OpenID Connect, noch met een andere standaard met dat doel. Dat wil niet zeggen dat zulke standaarden niet op andere toekomstige koppelvlakken in het MedMij Afsprakenstelsel toegepast kunnen gaan worden, op koppelvlakken dus die juist wel voor identiteitsdienstverlening bedoeld zijn, in plaats van voor autorisatie. De standaarden OAuth 2.0 en SAML 2.0 — als voorbeeld; de gekozen Authentication Service kan een ander koppelvlak gebruiken dan SAML — hebben dus verschillende doelen: OAuth voor autorisatie en SAML voor authenticatie. Dat zorgt er onder andere voor dat de rolstructuur anders is. In OAuth is er een gebruiker (Resource Owner) die via zijn browser of app (User Agent) aan de ene applicatie (Client) toegang verleent aan een andere (Resource Server), welke laatste zich daarvoor laat bijstaan door een Authorization Server. In SAML is er een gebruiker die via een browser of app (User Agent) inlogt bij een dienst (Service Provider), die zich daarvoor laat bijstaan door een Identity Provider. Toch zitten er belangrijke overeenkomsten tussen de manieren waarop ze werken.
|
Info | ||
---|---|---|
| ||
In artikel 7 wordt het MedMij-verkeer afgebakend, met het oog op de Netwerk-laag. Al het MedMij-verkeer is over domeingrenzen. Bovendien maakt noch eventueel verkeer tussen PGO Presenter en PGO User Agent, noch eventueel verkeer tussen Authorization Server en Resource Server deel uit van MedMij-verkeer. Ook authenticatieverkeer is uitgesloten, omdat het MedMij Afsprakenstelsel geen eisen oplegt over welke (externe) Authentication Service wordt gebruikt. Het MedMij Afsprakenstelsel vereist dát er een passende authenticatie door Zorgaanbieder moet plaatsvinden, maar het verkeer dat daarvoor nodig is — tussen Authorization Server, Authentication Service en PGO User Agent — is geen MedMij-verkeer. Het is de Zorgaanbieder die niettemin als verwerkingsverantwoordelijke verantwoordelijk blijft voor een passende keuze van een Authentication Service en voor het laten inrichten van het authenticatieverkeer. Deze afbakening is bovendien de opmaat voor punt 8 erna. Het daarin gemaakte onderscheid tussen frontchannel- en backchannelverkeer is nodig voor het formuleren van verantwoordelijkheden over beveiliging (zie Netwerk-laag). In punt 7 moet ermee rekening gehouden worden dat er ook een use case-implementatie is op de Netwerk-laag: UCI Opvragen WHL. |
Verantwoordelijkheden
Use cases en Gegevensdiensten
...
title | Toelichting |
---|
Van de meeste use cases (zie de laag Processen en Informatie) wordt op deze (Applicatie)laag een use case-implementatie (UCI) voorgeschreven. Het gaat om de volgende.
...
Hier worden de rollen van de Processen-en-Informatie-laag vertaald naar rollen op applicatieniveau. Voor de algemene uitgangspunten inzake de getalsverhoudingen tussen de rollen, zie de pagina Architectuur en technische specificaties.
In het persoonsdomein zijn drie rollen onderscheiden: de PGO Presenter, PGO User Agent en de PGO Server. Dat is nodig om de verbinding te kunnen leggen met de rollen volgens OAuth. PGO Presenter en PGO User Agent zijn alle front-end-rollen voor de PGO Server, en kunnen bijvoorbeeld allebei in een browser zijn geïmplementeerd, maar voor een goede binding aan de OAuth- en Authentication-rollen en voor een goede beveiligingsmaatregelen is het nodig deze twee rollen te scheiden. Zoals ook elders in het MedMij Afsprakenstelsel gaat het hier om rollen, om setjes verantwoordelijkheden dus, niet om implementatiecomponenten.
In het Zorgaanbiedersdomein is zo'n scheiding niet nodig. Waar een Persoon zelf operationeel betrokken wordt in het informatieverkeer — namelijk om zich te laten authenticeren, en het verkeer te laten autoriseren — laat de Zorgaanbieder zich operationeel geheel vertegenwoordigen door zijn Dienstverlener en diens Authorization Server en Resource Server. Ook al zal in veel gevallen de gezondheidsinformatie uiteindelijk uit een achterliggend systeem worden betrokken, voor het MedMij Afsprakenstelsel is dat geen kwestie. Het is voldoende om bij de Authorization Server en Resource Server de eindverantwoordelijkheid neer te leggen (black box).
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
De rollen Authorization Server en respectievelijk Resource Server (in UCI Verzamelen en UCI Delen) of Subscription Server (in UCI Abonneren) werken in het MedMij-afsprakenstelsel samen in eenzelfde ononderbroken sessie. Hun onderlinge relatie is een proceskoppeling. Dat wil zeggen, zij worden georkestreerd onder de hoede van één procesgang. Rollen in het MedMij Afsprakenstelsel zijn echter groepjes verantwoordelijkheden, geen implementatiecomponenten. Het is daarmee aan de Dienstverlener zorgaanbieder om in zijn implementatie, en business model, keuzes te maken over het scheiden of juist combineren van deze twee rollen. Als de rollen gescheiden zijn is het bovendien goed mogelijk om één Authorization Server of Subscription Server te laten samenwerken met meerdere Resource Servers en om één Resource Server zaken te laten doen met meerdere Authorization Servers of Subscription Servers. Steeds echter zullen zij samen het gedrag moeten vertonen dat wordt geëist door het MedMij Afsprakenstelsel. Overigens maakt ook de OAuth-specificatie gewag van deze implementatievrijheid.
Omdat de sessiecoördinatie in het Zorgaanbiederdomein zich over het scheidsvlak tussen Authorization Server en Resource Server of Subscription Server uitstrekt, moet er in geval van gescheiden implementatie van Authorization Server en Resource Server of Subscription Server een interface worden gerealiseerd waarin die sessiecoördinatie in stand blijft. Bovendien moet, als de relatie tussen Authorization Server en Resource Server of Subscription Server niet één-op-één is, ervoor worden gezorgd dat de juiste twee elkaar vinden bij de communicatie over een specifiek access token.
Ondanks deze implementatievrijheid hebben de verantwoordelijkheden in het MedMij Afsprakenstelsel invloed op de implementatie-architectuur in het Zorgaanbiedersdomein. Met name vereist de adressering dat er voor één combinatie van Zorgaanbieder, Gegevensdienst, Interfaceversie (en Systeemrol) maar één authorization endpoint en één token endpoint (en één resource endpoint of subscription endpoint) kan zijn. Bovendien voorkomen beperkingen op de informatie-inhoud van authorization codes en access tokens dat het interface tussen Authorization Server en Resource Server of Subscription Server via het Persoonsdomein wordt gerealiseerd. Op enkele uitzonderingen na is dat interface een interne aangelegenheid van het Zorgaanbiedersdomein. Daarmee worden zowel principes P1 en P7 gediend, alsook dataminimalisatie, en dus de privacy. De belangrijkste uitzondering is dat de authorization code en het access token desgewenst een identificatie mogen bevatten van de service die het heeft uitgegeven. Daarmee kan de (voorziene) acceptant van de authorization code of het access token de Authorization Server of Subscription Server vinden waar de validatie van de authorization code of het access token moet plaatsvinden.
Zelfs als er sprake is van gescheiden implementatie, is het nog steeds één Dienstverlener Zorgaanbieder die eindverantwoordelijk is, jegens MedMij, voor het gezamenlijke gedrag van Authorization Server en Resource Server of Subscription Server. Dat betekent dat de interoperabiliteit tussen Authorization Server en Resource Server of Subscription Server moet vallen onder de overeenkomst die de betreffende Dienstverlener zorgaanbieder aangaat met eventuele onderaannemers, bijvoorbeeld als de Dienstverlener zorgaanbieder zelf de Resource Server of Subscription Server exploiteert maar een onderaannemer voor de Authorization Server contracteert. Zie ook de toelichting, onder de Rollen op de Netwerk-pagina, van hoe op netwerkniveau met Nodes wordt omgegaan indien een Dienstverlener zorgaanbieder gebruik zou maken van onderaannemers voor bijvoorbeeld AuthorizationServer- of Subscription Server-functionaliteit..
Het is denkbaar dat een community van dienstverleners in het Zorgaanbiedersdomein tot een afsprakenstelsel komt, aanpalend aan en voldoend aan het MedMij Afsprakenstelsel, waarin de interne architectuur van het Zorgaanbiedersdomein aan de orde is. Naast bovenbedoelde scheiding zouden daarin bijvoorbeeld ook architectuurkeuzes over de beschikbaarheids- en ontvankelijkheidstoets kunnen worden opgenomen.
Autorisatie versus authenticatie
Het is van belang om een heldere scheiding te maken tussen autorisatie en authenticatie in het MedMij Afsprakenstelsel. Niet alleen zijn het verschillende functionaliteiten, authenticatie voor vaststelling van identiteit en autorisatie voor het beheren van toegangsrechten, de bijbehorende rollen kunnen in het MedMij Afsprakenstelsel niet zomaar worden gecombineerd. De Authorization Server heeft de rol om, namens de Zorgaanbieder, op verzoek van de Persoon, autorisaties uit te delen aan de PGO Server. Om dat betrouwbaar te kunnen doen, en om aan een wettelijke verplichting van de Zorgaanbieder invulling te geven, schakelt de Authorization Server de (externe) Authentication Service in.
Dat betekent echter niet dat de Authorization Server op haar beurt identiteitsdiensten gaat verlenen aan de PGO Server, door bijvoorbeeld een aan de BSN gekoppelde identiteit mee te geven met het acces token dat ze uitdeelt. Dat zou oneigenlijke verbreding zijn van haar authenticatierol, die begrensd zou moeten blijven tot de verantwoordelijkheden jegens de Zorgaanbieder en zich niet moet uitstrekken tot het bedienen van de PGO Server. Bovendien zou het een centrum van Persoons-identiteit creëren in het MedMij-landschap die, gezien de regiedoelstellingen van MedMij, bij voorkeur niet in het Zorgaanbiedersdomein ligt, maar in het Persoonsdomein, en daarbinnen bij voorkeur zo dicht mogelijk bij de Persoon zelf.
Daarom vindt er op het koppelvlak tussen PGO Server en Authorization Server geen uitwisseling van Persoons-identiteiten plaats, niet met bijvoorbeeld de standaard OpenID Connect, noch met een andere standaard met dat doel. Dat wil niet zeggen dat zulke standaarden niet op andere toekomstige koppelvlakken in het MedMij Afsprakenstelsel toegepast kunnen gaan worden, op koppelvlakken dus die juist wel voor identiteitsdienstverlening bedoeld zijn, in plaats van voor autorisatie.
De standaarden OAuth 2.0 en SAML 2.0 — als voorbeeld; de gekozen Authentication Service kan een ander koppelvlak gebruiken dan SAML — hebben dus verschillende doelen: OAuth voor autorisatie en SAML voor authenticatie. Dat zorgt er onder andere voor dat de rolstructuur anders is. In OAuth is er een gebruiker (Resource Owner) die via zijn browser of app (User Agent) aan de ene applicatie (Client) toegang verleent aan een andere (Resource Server), welke laatste zich daarvoor laat bijstaan door een Authorization Server. In SAML is er een gebruiker die via een browser of app (User Agent) inlogt bij een dienst (Service Provider), die zich daarvoor laat bijstaan door een Identity Provider.
Toch zitten er belangrijke overeenkomsten tussen de manieren waarop ze werken.
- Beide gaan ervan uit dat de eindgebruiker zich aandient via een betrekkelijk onveilig kanaal (de User Agent, het "front-channel"), terwijl er ook gevoeliger informatie moet worden uitgewisseld ("back-channel"), dat niet via dit kanaal verloopt.
- Bij beide moet de User Agent aan de hand worden genomen en heen- en teruggestuurd (redirect). Bij OAuth is dat van de Client naar de Authorization Server en terug. Bij SAML is dat van de Service Provider naar de Identity Provider en terug.
- Bij beide krijgt de Client (bij OAuth de Client en bij SAML de Service Provider) niet onmiddellijk de gewenste informatie (bij OAuth het access token en bij SAML de gebruikersidentiteit), maar via een ophaalbewijs (bij OAuth de authorization code, bij SAML het artefact). Het ophaalbewijs gaat voorlangs (via de User Agent), waarna achterlangs met het ophaalbewijs de gewenste informatie wordt opgehaald.
MedMij-Verkeer
In artikel 7 van het hoofdstuk 'Rollen' wordt het MedMij-verkeer afgebakend, met het oog op de Netwerk-laag. Al het MedMij-verkeer is over domeingrenzen. Bovendien maakt noch eventueel verkeer tussen PGO Presenter en PGO User Agent, noch eventueel verkeer tussen Authorization Server en Resource Server deel uit van MedMij-verkeer. Ook authenticatieverkeer is uitgesloten, omdat het MedMij Afsprakenstelsel geen eisen oplegt over welke (externe) Authentication Service wordt gebruikt. Het MedMij Afsprakenstelsel vereist dát er een passende authenticatie door Zorgaanbieder moet plaatsvinden, maar het verkeer dat daarvoor nodig is — tussen Authorization Server, Authentication Service en PGO User Agent — is geen MedMij-verkeer. Het is de Zorgaanbieder die niettemin als verwerkingsverantwoordelijke verantwoordelijk blijft voor een passende keuze van een Authentication Service en voor het laten inrichten van het authenticatieverkeer.
Deze afbakening is bovendien de opmaat voor punt 8 erna. Het daarin gemaakte onderscheid tussen frontchannel- en backchannelverkeer is nodig voor het formuleren van verantwoordelijkheden over beveiliging (zie Netwerk-laag). In punt 7 moet ermee rekening gehouden worden dat er ook een use case-implementatie is op de Netwerk-laag: UCI Opvragen WHL.
Verantwoordelijkheden
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. |
...
|
...
| |
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 gebruik gemaakt 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:
|
18. OAuth Client, OAuth Authorization Server en OAuth Resource Server implementeren de op deze respectievelijke rollen toepasselijke beveiligingsmaatregelen, volgens paragaaf 5.3 van RFC6750.
Info | ||
---|---|---|
| ||
Deze verantwoordelijkheid is opgenomen omdat met het bearer token informatie verkregen kan worden zonder dat nogmaals de identiteit wordt gecontroleerd. Daarom moeten maatregelen getroffen worden om te waarborgen dat het token alleen correct gebruikt kan worden
|
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. |