RFC0063 Poortnummer toestaan voor redirect_uri

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	Former user (Deleted)
Implementatietermijn	1.6.0
Motivatie verkorte RFC procedure (patch)

Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
Productmanager Stichting MedMij			Productmanager Beheerorganisatie
Leadarchitect Stichting MedMij			Leadarchitect Beheerorganisatie
Ontwerpteam
Deelnemersraad			Eigenaarsraad

Principe's

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:

~~Toelichting~~
~~Dat geldt dus ook voor de redirect_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 bij https hoort (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 voor https bedoelde 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_id ~~en er geen poortnummer is opgenomen~~
de redirect_uri moet volledig zijn en verwijzen naar een https-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 https gebruikt. 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

	File	Modified

No files shared here yet.