Overzicht van de architectuur
![](https://vzvz.atlassian.net/wiki/download/attachments/136414475/MedMij,%201.3.0,%20Architectuur%20Afsprakenstelsel%20MedMij-Applicatie.png?version=1&modificationDate=1616402850627&cacheVersion=1&api=v2)
 Toelichting
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:
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: - 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.
|
2. | 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.
|
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: - 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.
 Toelichting 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. |
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: - 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,
met dien verstande dat: - 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.
|
8. | Al het MedMij-verkeer, voor zover daarin de PGO User Agent: - betrokken is, heet frontchannel-verkeer;
- niet betrokken is, vormt het backchannel-verkeer.
|
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 Authorization Server- 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.  Toelichting De gebruikersbeleving wordt het best bediend door de gehele procesgang ononderbroken te houden. |
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.  Toelichting Zo wordt geborgd dat de juiste use case-implementaties en informatiestandaarden worden gebruikt. Ook wordt het correcte gebruik geborgd, wat bijdraagt aan interoperabiliteit en vertrouwen. |
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.  Toelichting Conform wettelijke verplichting geeft Zorggebruiker, in de UC Verzamelen en de UC Abonneren, actief toestemming aan de Zorgaanbieder. In de UC Delen is deze verplichting niet aan de orde, maar vindt op dit moment evengoed een bevestiging door de Zorggebruiker plaats. De PGO Presenter presenteert een venster waarin de Zorggebruiker deze toestemming, respectievelijk bevestiging, kan geven. Aangezien in het persoonsdomein niet met BSN gewerkt mag worden, moet er een vervangende identificatie van de zorggebruiker gebruikt worden. Zie verantwoordelijkheid 5. |
4. | Van de vier soorten authorization grants die OAuth 2.0 biedt, beperken de OAuth-rollen zich tot Authorization Code. Â Toelichting Met deze ene soort kunnen alle situaties die in het MedMij Afsprakenstelsel voorkomen worden bediend. Voor het maximaliseren van de interoperabiliteit kiest MedMij ervoor de andere drie soorten uit te sluiten. |
5. | De OAuth Client en OAuth Resource Server zullen slechts tokens van het type Bearer Token uitwisselen, conform RFC6750.  Toelichting De OAuth-standaard laat het (access) token type vrij. Token types verschillen in het vertrouwen waarmee de Resource Server aan de Client de gevraagde resources kan prijsgeven als laatstgenoemde het access token aan eerstgenoemde overlegt. Bij de eenvoudigste vorm (Bearer Token) geeft de Resource Server eenvoudigweg aan elke Client die een geldig access token overlegt, de resources die daarbij horen. "Aan toonder", net zoals een bank een cheque kan verzilveren aan toonder. Daaraan kleven evenwel veiligheidsrisico's, omdat het access token na uitgifte gestolen kan zijn, of anderszins vervreemd van de Client aan wie het uitgedeeld was. Andere token types kunnen daarom vragen om meer garanties, zoals een identiteit van de Client of een client secret. Bearer Token is echter het enige goed gestandaardiseerde en breed gebruikte token type. Het legt wel veel verantwoordelijkheid voor beheersing van de veiligheidsrisico's bij Client en Authorization Server. In hoofdstuk 5 van de specificatie van de standaard RFC6750 is daarom expliciete aandacht voor die beveiligingsrisico's en maatregelen om die het hoofd te bieden. Zie hiervoor verantwoordelijkheid 18. |
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.  Toelichting Bij het genereren van codes en tokens is de OAuth-scope meegenomen. Deze is gerelateerd aan de Gegevensdienst. Hoewel het technisch mogelijk is om meerdere scopes mee te geven is de scope beperkt tot één Gegevensdienst per keer. |
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.  Toelichting Dit is een maatregel tegen de beveiligingsrisico's 4.4.1.1 en 4.4.1.3 uit RFC 6819. Bovendien wordt de hele flow van Verzamelen ononderbroken uitgevoerd (zie onder 1). De 900 seconden moeten dan voldoende zijn voor de Client om het access token aan de Authorization Server aan te bieden. Een refresh token is dan niet nodig. |
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:- een identifier van de authorization code, respectievelijk het access token, indien die identifier op zichzelf voldoet aan de in verantwoordelijkheid 8a genoemde eisen;
- een verloopmoment van de geldigheid van het token, onder de voorwaarden dat zowel:
- de waarde daarvan in overeenstemming is met de verantwoordelijkheden in het MedMij Afsprakenstelsel en
- uit het verstreken zijn daarvan wél de ongeldigheid van de authorization code of het access token mag worden geconcludeerd door de Authorization Server of de Resource Server, maar uit het nog niet verstreken zijn daarvan niet diens geldigheid, waarvoor namelijk een validatie van het gehele token tegen de interne administratie van de Authorization Server de enige autoriteit is;
- een identificatie van de service die het token heeft uitgegeven;
- de
scope waarvoor de authorization code of het access token is uitgegeven, in de vorm van een kopie van de scope -parameter van de authorization request in antwoord waarop de authorization code of het access token is uitgegeven; - de naam van het token-formaat;
- een digitale handtekening.
|
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.  Toelichting Dit is een maatregel tegen beveiligingsrisico 4.4.1.3 uit RFC 6819. Aan de in omloop gebrachte authorization codes en access tokens zijn twee belangrijke eisen te stellen: uniciteit en vertrouwelijkheid. De eis van vertrouwelijkheid weegt in het MedMij Afsprakenstelsel zwaar. Omdat de authorization code (indirect) en het access token (direct) toegang geven tot persoonlijke gezondheidsinformatie, kiest MedMij voor een formaat dat vrijwel betekenisloos is en alleen betekenis krijgt door confrontatie met lokale en goed beschermde administraties van de Authorization Server. De maximale raadkans wordt geëist in RFC6749, sectie 10.10. Er mag door vergelijking van meerdere authorization codes of access tokens niet doorschemeren hoe zij gegenereerd worden.
Wanneer een identifier is opgenomen in het access token, kan dat gebruikt worden als identificatie van de Authorization Server-sessie waarin het token werd uitgegeven, zodat de Resource Server deze sessie kan hervatten wanneer zij het access token aangeboden krijgt. Het is ook mogelijk dat een dergelijke identifier niet zozeer is opgenomen in de authorization code, respectievelijk het access token, maar geheel overeenkomt met de authorization code, respectievelijk het access token. Hoe dan ook, verantwoordelijkheid 8a blijft erop van kracht. Wanneer een verloopmoment is opgenomen in het access token, wordt het mogelijk om de Resource Server te laten afzien van onnodige raadpleging van de Authorization Server, wanneer deze apart geïmplementeerd zouden zijn. De tweede voorwaarde bij deze mogelijkheid voorkomt dat een eventuele corrumpering, in het Persoonsdomein, van de authorization code of het access token waarbij het verloopmoment verlaat zou worden, leidt tot onterechte toegang tot, of onterechte plaatsing van gezondheidsinformatie. Het accepteren van een authorization code of een access token gebeurt altijd in het licht van de interne administratie van de Authorization Server. Die corrumpering kan het verloopmoment ook vervroegen, maar richt dan weinig schade aan. Overigens kan in de deze versie van het MedMij Afsprakenstelsel, waarin de geldigheidsduur een vaste waarde heeft, de OAuth Client zelf ook al uitrekenen wanneer het geen zin meer heeft een authorization code of access token nog aan te bieden. De meerwaarde van het opnemen van een verloopmoment in de authorization code of het access token zal dus hooguit in mogelijke toekomstige versies kunnen blijken. De service die het token heeft uitgegeven is al wel in deze versie van het MedMij Afsprakenstelsel een nuttig informatie-element. In situaties waarin een Resource Server samenwerkt met meerdere van hem gescheiden geïmplementeerde Authorization Servers, moet deze bij een aangeboden access token kunnen bepalen welke Authorization Server moet worden aangesproken. Dat aanspreken kan bijvoorbeeld door middel van Token Introspection volgens RFC7662. De geëigende bron voor die informatie is het access token zelf, dat weet heeft van zijn afkomst. Die afkomstinformatie levert geen extra privacyrisico's op, omdat de OAuth Client sowieso op de hoogte is van wie hij het access token heeft ontvangen. Verder mag de OAuth Authorization Server ook een kopie van de scope opnemen in (de authorization code of) het access token, de scope die hij eerder in de authorization request heeft ontvangen van de OAuth Client (zie Authorization interface, verantwoordelijkheid 1). Zo hoeft de Resource Server niet apart door de PGO Server van de scope op de hoogte gebracht te worden. De authorization code of het access token draagt zo weliswaar extra betekenis, maar de risico's daarvan wegen niet op tegen de risico's van het apart door de PGO Server laten sturen van de scope, die bijvoorbeeld zou kunnen afwijken van die waarvoor de authorization code of het access token is uitgegeven. De lijst van toegestane informatie-elementen is limitatief. Geen andere informatie, ook niet versleuteld, mag in de authorization code of het access token zijn opgenomen. Daaronder vallen zeker ook: - informatie over Persoon;
- informatie over Zorgaanbieder of Gegevensdienst, al dan niet in relatie tot Persoon, buiten de
scope ; - benoeming van, en beperkingen aan, de beoogde acceptanten van de authorization code of het access token. Op dit punt is namelijk de Zorgaanbiederslijst de autoriteit: als de OAuth Client een access token heeft opgehaald op een plek die daartoe in de Zorgaanbiederslijst stond, dan moet hij dat access token kunnen aanbieden aan de plek die daartoe in de Zorgaanbiederslijst staat.
Het verbod op interpretatie door de OAuth Client van authorization code en access token zorgt ervoor dat er een minimale afhankelijkheid wordt gecreëerd tussen de dienstverleners in het Persoonsdomein enerzijds en die in het Zorgaanbiedersdomein anderzijds, zodat principes P1 en P7 maximaal worden nageleefd en interne complexiteit en implementatiekeuzes in het Zorgaanbiedersdomein niet doorschemeren in, of invloed uitoefenen op, de implementatie in het Persoonsdomein. De beperkingen van betekenisdragendheid van de authorization code en het access token, zelfs indien versleuteld, bevorderen de privacy door middel van dataminimalisatie. Bovendien voorkomen zij nieuwe risico's op compromittering van die informatie-inhoud. Zulke compromittering zou moeilijk te ontdekken en te pareren zijn in het zorgaanbiedersdomein, ingeval men er daar toe besloten zou hebben van interne autorisatie-administratie af te zien omdat de informatie toch al meereist op de authorization code of het acces token, via de OAuth Client.
|
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: - IETF RFC 6749, De code moet zijn uitgegeven aan de opgegeven client_id.
- IETF RFC 8705, Bij het verzoek naar het token-endpoint wordt gebruikgemaakt van een certificaat, waarvan de Common name geregistreerd is bij de opgegeven client_id.
|
9. | Het OAuth-client type van de OAuth Client is confidential.  Toelichting Om de privacy te kunnen borgen is het van belang dat de OAuth Authorization Server voldoende zekerheid heeft over de identiteit van de OAuth Client. Die zekerheid is afhankelijk van hoe goed de OAuth Client zijn credentials vertrouwelijk kan houden. Daartoe maakt de OAuth-specificatie onderscheid tussen twee client types: confidential en public. De eerste soort kan een voor de Authorization Server afdoende mate van vertrouwelijkheid van zijn credentials bieden, de tweede niet. Het is een hoofddoel van MedMij om zulk vertrouwen te borgen in een afsprakenstelsel en niet over te laten aan individuele spelers. Daarom verbindt het MedMij Afsprakenstelsel verantwoordelijkheden aan Clients ten behoeve van hun betrouwbaarheid jegens Authorization Servers. We verwachten dat een groot deel van de implementaties van de Oauth Client (van de PGO Server dus) deze vertrouwelijkheid sowieso kunnen bieden, omdat ze de architectuur hebben van wat de OAuth-specificatie web application noemt. Andersoortige PGO Server-architecturen, zoals die van een app, zijn ook mogelijk, maar alleen onder de voorwaarde dat de OAuth Client al het credentials-verkeer in de achtergrond op een server afhandelt, niet via het user device. |
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 PKI-certificaten, en wel servercertificaten, ten behoeve van de authenticatie van de andere server in een uitwisseling. Â Toelichting Dit is een maatregel tegen beveiligingsrisico's 4.4.1.1, 4.4.1.3, 4.4.1.4 en 4.4.1.5 in RFC 6819. De PKI-certificaten worden in deze release van het MedMij Afsprakenstelsel gebruik voor twee doelen op de Netwerklaag: authenticatie van servers en versleuteling, waarmee de vertrouwelijkheid en integriteit van de inhoud van het gegevensverkeer wordt geborgd. |
15. | De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC6819: beveiligingsmaatregel | paragraaf in RFC6819 | gemitigeerde risico('s) |
---|
Clients should use an appropriate protocol, such as OpenID or SAML to implement user login. Both support audience restrictions on clients. | 4.4.1.13 | 4.4.1.13 | All clients must indicate their client ids with every request to exchange an authorization "code" for an access token. |
|
| Keep access tokens in transient memory and limit grants. | 5.1.6 |
| Keep access tokens in private memory. | 5.2.2 | 4.1.3 | The "state" parameter should be used to link the authorization request with the redirect URI used to deliver the access token. | 5.3.5 | 4.4.1.8 | CSRF defense and the "state" parameter created with secure random codes should be deployed on the client side. The client should forward the authorization "code" to the authorization server only after both the CSRF token and the "state" parameter are validated. | 4.4.1.12 |
|
|
16. | De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC6819: beveiligingsmaatregel | paragraaf in RFC6819 | gemitigeerde risico('s) |
---|
Client applications should not collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g., the system browser. | 4.1.4 | 4.1.4 | The client server may reload the target page of the redirect URI Â in order to automatically clean up the browser cache. | 4.4.1.1 | 4.4.1.1 | If the client authenticates the user, either through a single-sign-on protocol or through local authentication, the client should suspend the access by a user account if the number of invalid authorization "codes" submitted by this user exceeds a certain threshold. | 4.4.1.12 | 4.4.1.12 | Client developers and end users can be educated to not follow untrusted URLs. | 4.4.1.8 | 4.4.1.8 | For newer browsers, avoidance of iFrames during authorization can be enforced on the server side by using the X-FRAME-OPTIONS header. For older browsers, JavaScript frame-busting techniques can be used but may not be effective in all browsers. | 5.2.2.6 | 4.4.1.9 | Explain the scope (resources and the permissions) the user is about to grant in an understandable way | 5.2.4.2 | 4.2.2 |
|
17. | De OAuth Authorization Server realiseert de volgende beveiligingsmaatregelen, conform RFC6819: beveiligingsmaatregel | paragraaf in RFC6819 | gemitigeerde risico('s) |
---|
Authorization servers should consider such attacks: Password Phishing by Counterfeit Authorization Server | 4.2.1 | 4.2.1 | Authorization servers should attempt to educate users about the risks posed by phishing attacks and should provide mechanisms that make it easy for users to confirm the authenticity of their sites. |
|
| Authorization servers should decide, based on an analysis of the risk associated with this threat, whether to detect and prevent this threat. | 4.4.1.10
| 4.4.1.10
| The authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. |
|
| The authorization server could make use of CAPTCHAs. |
|
| The authorization server should consider limiting the number of access tokens granted per user. | 4.4.1.11 | 4.4.1.11 | The authorization server should send an error response to the client reporting an invalid authorization "code" and rate-limit or disallow connections from clients whose number of invalid requests exceeds a threshold. | 4.4.1.12 | 4.4.1.12 | Given that all clients must indicate their client ids with every request to exchange an authorization "code" for an access token, the authorization server must validate whether the particular authorization "code" has been issued to the particular client. | 4.4.1.13 | 4.4.1.13 | Best practices for credential storage protection should be employed. | 5.1.4.1 | 4.4.1.2 | Enforce system security measures. | 5.1.4.1.1 | 4.3.2 en 4.4.1.2
| Enforce standard SQL injection countermeasures. | 5.1.4.1.2 |
| Store access token hashes only. | 5.1.4.1.3 |
| The authorization server should enforce a one-time usage restriction. | 5.1.5.4 | 4.4.1.1 | If an authorization server observes multiple attempts to redeem an authorization "code", the authorization server may want to revoke all tokens granted based on the authorization "code". | 5.2.1.1 |
| Bind the authorization "code" to the redirect URI. | 5.2.4.5 | 4.4.1.3 | the authorization server associates the authorization "code" with the redirect URI of a particular end-user authorization and validates this redirect URI with the redirect URI passed to the token's endpoint, | 4.4.1.7 |
|
|
18. | OAuth Client, OAuth Authorization Server en OAuth Resource Server implementeren de op deze respectievelijke rollen toepasselijke beveiligingsmaatregelen, volgens paragaaf 5.3 van RFC6750.  Toelichting 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. |
 Toelichting
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:
- handles i.p.v. assertions, zodat de OAuth Resource Server moet kunnen refereren aan data van de OAuth Authorization Server;
- bearer tokens i.p.v. proof tokens. Zie hiervoor verantwoordelijkheid 5 op deze laag.
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:
- maatregelen waarin al is voorzien door één of meerdere verantwoordelijkheden in het MedMij-afsprakenstelsel, zoals bijvoorbeeld:
- maatregelen die weliswaar door RFC6819 worden gesuggereerd, maar niet worden overgenomen in het MedMij Afsprakenstelsel, omdat zij niet passen bij diens principes of bij andere verantwoordelijkheden in het stelsel;
- overige maatregelen, die alsnog getroffen dienen te worden door PGO Server, OAuth Client of OAuth Authorization Server en in verantwoordelijkheden 15-17 staan genoemd.
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. |