Samenvatting
| Waarom is deze RFC nodig? | In Release 1.1.2 van het AS is besloten om het poortnummer te verbieden in alle url's binnen MedMij en impliciet de https poortnummers te verplichten. In de praktijk blijkt dat dit voor een deelnemer problematisch is. Bij het terugverwijzen van de authorization server naar de client kan nu geen poortnummer worden opgegeven in de redirect_uri, waardoor de mogelijkheden van routeren van het verkeer beperkt zijn. Er moet een heroverweging gemaakt wordt tussen het forceren dat beveiligd https verkeer wordt toegepast en de mogelijkheid bied om complexere routering mogelijk te maken voor deelnemers (met zowel kans op onveiligheid als mogelijkheden het beveiligingsniveau te verbeteren). |
|---|---|
| Oplossingsrichting | Poortnummer toestaan op redirect_uri. Dit is een kleine stap (OAuth2 staat een volledige uri toe als redirect_uri) en in combinatie met de verplichting om https (en tls) toe te passen zal dit niet leiden tot een vermindering van het beveiligingsniveau van MedMij. |
| Aanpassing van | Afsprakenstelsel |
| Impact op rollen | DVZA (beperkt en wijziging formaat OCL), DVP (beperkt, daarnaast meer mogelijkheden bij inrichten infrastructuur) |
| Impact op beheer | Controle inrichten op correcte toepassing |
| Impact op RnA | Ja, redirect_uri krijgt nieuwe regels en formaat. |
| Impact op Acceptatie | Wijziging formaat redirect_uri en OCL. |
| PIA noodzakelijk | |
| Gerelateerd aan (Andere RFCs, PIM issues) | |
| Eigenaar | |
| Implementatietermijn | 1.6.0 |
| Motivatie verkorte RFC procedure (patch) |
...
| Principe | Principe | ||
|---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | 11 Stelselfuncties worden vanaf de start ingevuld | ||
| 2 Dienstverleners zijn transparant over de gegevensdiensten | 12 Het afsprakenstelsel is een groeimodel | ||
| 3 Dienstverleners concurreren op de functionaliteiten | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | ||
| 4 Dienstverleners zijn aanspreekbaar door de gebruiker | 14 Uitwisseling is een keuze | ||
| 5 De persoon wisselt gegevens uit met de zorgaanbieder | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | ||
| 6 MedMij spreekt alleen af wat nodig is | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | ||
| 7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | ||
| 9 De dienstverleners zijn deelnemers van het afsprakenstelsel | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | ||
| 10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | ||
| Toelichting | |||
Uitwerking
...
Op pagina Verantwoordelijkheden, Core verwijderen:
Dat geldt dus ook voor deredirect_uri.
In release 1.1.1 van het MedMij Afsprakenstelsel was deze verantwoordelijkheid alleen van toepassing op frontchannel-verkeer en had de Dienstverlener aanbieder voor back-channelverkeer de vrijheid om een ander poortnummer te kiezen dan dat conform de IANA-lijst bijhttpshoort (443). Dat zorgt echter voor een extra beveiligingsbeheerlast bij de DVP Server die rekening houden met meerdere bestemmingspoortnummers bij uitgaand verkeer. Die beheerst brengt indirect ook extra beveiligingsrisico's met zich mee. Daartegenover staat dat de in deze release aangebrachte aanscherping naar verwachting geen wezenlijke beperking voor Dienstverleners aanbieder zal zijn, omdat zij toch al gebruik maken van het voorhttpsbedoelde poortnummer uit de IANA-lijst. Een mogelijke uitzondering vormt de situatie waarin de Authorization Server en/of Resource Server in een multi-tenant omgeving draaien.
Op pagina Authorization interface verwijderen:
redirect_uri
- zodanig dat de erin opgenomen hostname gelijk is aan de
client_iden er geen poortnummer is opgenomen- de
redirect_urimoet volledig zijn en verwijzen naar eenhttps-beschermd endpoint- de redirect_uri moet urlencoded zijn (conform RFC 3986)
Zie verantwoordelijkheden 1 en 2a op de pagina Interfaces.
De tweede eis is een maatregel tegen beveiligingsrisico's 4.1.5, 4.2.4, 4.4.1.1, 4.4.1.5 en 4.4.1.6 in RFC 6819. Zie bovendien T
Op pagina Metamodel toevoegen:
Bij een ZorgaanbiederGegevensdienst hoort één AuthorizationEndpoint, één TokenEndpoint en, indien daarop ook Abonnementen worden aangeboden, één SubscriptionEndpoint. Bij een ZorgaanbiederGegevensdienstSysteemrol hoort één ResourceEndpoint. Bij alle soorten endpoints noemt het metamodel het Endpointpath, het path in de URI waarmee de endpoints geadresseerd worden, en een Interfaceversion, waarmee gelijktijdig operationele versies van dezelfde endpoints kunnen worden onderscheiden. In deze versie van het MedMij Afsprakenstelsel worden op zowel frontchannel als backchannel de standaard IANA-poort voor
httpsgebruikt. Er hoeven in de endpointadressen dus geen poortnummers te worden genoemd. Een uitzondering hierop is de request_uri, waarvoor wel een poortnummer mag worden opgegeven.
Geen impact op foutafhandeling (zie https://confluence.vzvz.nl/display/MMAS/Foutmeldingen+MedMij )
Risico's
Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.
| Dreiging | Kans | Impact | DreigingsID (intern) | Maatregelen |
|---|---|---|---|---|
| Door verkeerd configureren kan een redirect_uri met poortnummer (eenvoudiger) verwijzen naar onveilig http verkeer. | L | M | Controleren op opgegeven poortnummers. (Deelnemers kunnen elkaar hier ook onderling op aanspreken.) DVP's moeten redirect_uri vooraf opgeven, wordt niet dynamisch ingesteld bij aanroep. | |
| Fouten in routering bij redirect naar complexer adres. | L | H | DVP kan niet meer uitwisselen binnen MedMij. Dit zal snel gedetecteerd worden en probleem wordt ondervonden door partij die dit kan oplossen. |
Bijlagen
| Attachments |
|---|