De authorization interface hoort bij de hoofdfunctie Regie.
Op deze pagina staan alleen de verantwoordelijkheden inzake de authorization interface die nog niet genoemd staan in de OAuth 2-specificatie.
1
De OAuth Client voegt bij het versturen van een Authorization request twee HTTP query parameters toe, de eerste met de naam MedMij-Request-ID, de tweede met de naam X-Correlation-ID. Het MedMij-Request-ID moet een willekeurige waarde bevatten en dient uniek te zijn voor ieder request binnen het MedMij netwerk. De waarde bestaat uit een UUID. Het X-Correlation-ID moet een willekeurige waarde bevatten en dient uniek te zijn voor ieder authorization request binnen het MedMij netwerk. De waarde bestaat uit een UUID.
core.authint.208
2
De onderstaande parameters in de authorization request zijn verplicht en moeten als volgt gevuld worden.
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 Token interface, de toelichting onder verantwoordelijkheid 4.
scope
Voor "verzamelen":
MedMij-naam van de Aanbieder
Voor "delen":
één aanbieder-gegevensdienst-combinatie.
Een aanbieder-gegevensdienst-combinatie bestaat uit:
één Aanbiedernaam, ontdaan van de suffix @medmij
gevolgd door een tilde (~)
gevolgd door één GegevensdienstId van een Gegevensdienst uit de Gegevensdienstnamenlijst.
Er worden geen andere scopes of onderdelen van scopes opgenomen dan de genoemde.
Voorbeelden van syntactisch juiste scopes zijn:
Verzamelen:
"eenofanderezorgaanbieder", voor het uitwisselen van gegevens met eenofanderezorgaanbieder@medmij;
Delen:
"eenofanderezorgaanbieder~53", voor het eenmalig afnemen van Gegevensdienst53 bij eenofanderezorgaanbieder@medmij;
Hiermee geeft de OAuth Client informatie mee aan deOAuth Authorization Server, waaraan eerstgenoemde later, bij de redirect, kan afleiden bij welk verzoek de authorization code hoort. Deze informatie is verder betekenisloos voor de OAuth Authorization Server.
De state MOET
een minimale lengte hebben van 128 karakters (Voldoende lang om niet raadbaar te zijn).
een maximale lengte hebben van 512 karakters (Praktische grens, rekening houdend met standaard libraries en maximale lengte uri's).
MedMij-Request-ID
De waarde bestaat uit een UUID.
Het MedMij-Request-ID moet een willekeurige waarde bevatten en dient uniek te zijn voor ieder request binnen het MedMij netwerk.
X-Correlation-ID
De waarde bestaat uit een UUID.
Het X-Correlation-ID moet een willekeurige waarde bevatten en dient uniek te zijn voor ieder authorization request binnen het MedMij netwerk.
Het onderstaande voorbeeld dient als toelichting hoe het authorization request opgevuld zou moeten worden in het geval van de functie Verzamelen:
Authorisatie-interface
TYPE REQUEST: GET
https://authorization-server.com/auth?response_type=code
&client_id=medmij.deenigeechtepgo.nl
&redirect_uri=https%3A%2F%2Fmedmij.deenigeechtepgo.nl
&scope=eenofanderezorgaanbieder
&state=RGl0IGlzIGVlbiB2b29yYmVlbGQuIERlIHN0YXRlIHZ1bCBqZSBpbiBtZXQgYmlqdm9vcmJlZWxkIGVlbiBsb2thbGUgcmVmZXJlbnRpZSBvZiBKU09OLCBkZXplIGtvbXQgdGVydWcgb3AgcmVkaXJlY3RfdXJpLg
&MedMij-Request-ID=57510be1-73e6-4a75-9db8-ee005cced48f
&X-Correlation-ID=c0e7b545-9606-4eef-bea7-75d8addaa54b
In het geval van de functie Delen verandert de scope naar:
&scope=eenofanderezorgaanbieder~53
Conform de OAuth 2- specificatie moeten overige parameters die meegestuurd worden in het request genegeerd worden.
core.authint.200
3
De OAuth Client zorgt ervoor dat voor het authorization request de http-methode GET wordt gebruikt, niet POST.
Toelichting
In de OAuth-specificatie, sectie 3.1 wordt de OAuth Authorization Server verplicht gesteld GET te accepteren en wordt POST optioneel gehouden. Omdat GET de verreweg meest in het MedMij Afsprakenstelsel passende http-methode is voor de authorization request, geldt, om de OAuth Authorization Server niet voor onnodige implementatiekosten te plaatsen, deze verantwoordelijkheid. Hoewel deze verantwoordelijkheid een verantwoordelijkheid van de OAuth Client is, omdat deze onder de verantwoordelijkheid van een MedMij-deelnemer valt, wordt de request uiteindelijk door de User Agent uitgevoerd.
core.authint.201
4
Na ontvangst van een authorization request verifieert de Authorization Server dat:
de betreffende client_id voorkomt op de OAuth Client List;
de redirect_uri geldig is en voorkomt bij de betreffende client_id op de OAuth Client List.
Als een van deze verificaties niet slaagt dan behandelt de Authorization Server dit als uitzondering 1a volgens verantwoordelijkheid core.authint.207.
zij namens deze Aanbieder, voor de gehanteerde Interfaceversie, Gegevensdienst(en) ontsluit, in overeenstemming met de gepubliceerde Aanbiederslijst;
bij de functie Delen:
de gevraagde GegevensdienstId voor komt op de OAuth Client List, bij de betreffende client_id en voor de gehanteerde Interfaceversie;
de Gegevensdienst betrekking heeft op de functie Delen;
de hostnames van de AuthorizationEndpoints, waarop de Gegevensdienst wordt aangeboden, met elkaar overeenkomen;
de hostnames van de TokenEndpoints, waarop de Gegevensdienst wordt aangeboden, met elkaar overeenkomen.
Als een van deze verificaties niet slaagt dan behandelt de Authorization Server dit als uitzondering 1b volgens verantwoordelijkheid core.authint.207.
Toelichting
Zo voorkomt de Authorization Server dat gevolg wordt gegeven aan een verzoek dat blijkens de OAuth Client List of Aanbiederslijst niet is toegestaan.
core.authint.203
6
Tijdens de afhandeling van een authorization request laat de Authorization Server, in zijn rol als Authentication Client, voordat hij de Persoonom OAuth-autorisatie vraagt, de Persoon authenticeren door de Authentication Server.
Toelichting
Conform stroomdiagram onder 1. De Aanbiederin het Aanbiedersdomein, en dus BSN-domein, is verplicht bij het verstrekken van gegevens vanuit een gezondheidsdossier de identiteit van de persoon te verifiëren aan de hand van het BSN.
Het MedMij Afsprakenstelsel brengt het gebruik van de Authentication Server onder in de OAuth-flow, onder operationele verantwoordelijkheid van de Authorization Server. Laatstgenoemde handelt in dezen onder verantwoordelijkheid van individuele Aanbieders, want die zijn het waarvoor de Persoon zich authenticeert.
Voorafgaand aan uitgifte van een authorization code via de in de authorization request opgenomen redirect_uri, administreert de OAuth Authorization Server die authorization code en de daarvoor gebruikte redirect_uri.
conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied, met in de error description "Authorization failed."
Toelichting
De uitzonderingssituaties kunnen gezien worden als de implementatie-tegenhangers van de uitzonderingen van de functies Verzamelen en Delen. Op de Applicatielaag zijn deze echter per interface geordend. Alle uitzonderingen worden door de Authorization Server ontdekt. In deze versie van het MedMij Afsprakenstelsel is bepaald dat zij altijd leiden tot het zo snel mogelijk afbreken van de flow door alle betrokken rollen. Daartoe moeten echter eerst nog de andere rollen geïnformeerd worden. Om te voorkomen dat de DVP Server informatie over het bestaan van behandelrelaties verkrijgt zonder dat daarvoor (al) toestemming is gegeven, moet het onderscheid tussen de uitzonderingen 2, 3 en 4 niet te maken zijn door de DVP Server.
Deze tabel bevat alleen die uitzonderingssituaties ten aanzien waarvan het MedMij afsprakenstelsel eigen eisen stelt aan de implementatie. In de specificatie van OAuth 2.0 staan daarnaast nog generiekere uitzonderingssituaties, zoals de situatie waarin de redirect URI ongeldig blijkt. Ook deze uitzonderingssituaties moeten geïmplementeerd worden.
