RFC0008 Attribuut gebaseerde authenticatie

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Toelichting

Op de Applicatie-laag wordt beschreven dat de identiteit van de Zorggebruiker uitgedrukt wordt door een BSN en die passende zekerheid wordt verkregen door middel van DigiD.

DigiD

DigiD is dus de enig toegestane Authentication Service in de deze release van het MedMij Afsprakenstelsel. Zie hiervoor verder het Authorization interface.

MedMij-verkeer

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. Authenticatieverkeer is uitgesloten, omdat het MedMij Afsprakenstelsel geen eisen oplegt aan het koppelvlak met DigiD. 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.

MedMij-verkeer

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. Authenticatieverkeer is uitgesloten, omdat het MedMij Afsprakenstelsel geen eisen oplegt over welke authenticatieserver gebruikt moet worden. 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.

Authenticatie

Conform stroomdiagram onder 1. De zorgaanbieder in het Zorgaanbieders- 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. Uit het Juridisch kader volgt vooralsnog gebruik van DigiD voor dit doel. Omdat DigiD de enige is die de rol van Authentication Service kan spelen in deze release van het MedMij Afsprakenstelsel, is Logius de enige Authentication Provider ZA.

Het MedMij Afsprakenstelsel brengt het aanroepen van DigiD onder in de OAuth-flow, onder operationele verantwoordelijkheid van de Authorization Server. 

Laatstgenoemde handelt in dezen onder verantwoordelijkheid van individuele Zorgaanbieders, want die zijn het waarvoor de Persoon zich authenticeert. Voor DigiD in haar huidige status is dat in zoverre bijzonder dat de zich authenticerende Persoon niet de directe gebruiker is van de aanroeper van DigiD (en daar een gebruikerssessie krijgt), maar een indirecte gebruiker, namelijk door tussenkomst van de PGO Server.

De directe interactie van de Persoon met de Authorization Service is bedoeld om de PGO Server te autoriseren om de Resource Server aan te spreken. Die levert de uiteindelijke Gegevensdienst pas. Van oudsher is DigiD echter opgezet voor het authenticeren (inloggen en uitloggen) in gebruikerssessies bij dienstverleners. De MedMij-context is complexer dan dat. Voor de toekomst van DigiD wordt ook nagedacht over gebruikscontexten zoals die van MedMij.

Authenticatie

Conform stroomdiagram onder 1. De zorgaanbieder in het Zorgaanbieders- 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 aanroepen van de Authentication Service onder in de OAuth-flow, onder operationele verantwoordelijkheid van de Authorization Server. 

Laatstgenoemde handelt in dezen onder verantwoordelijkheid van individuele Zorgaanbieders, want die zijn het waarvoor de Persoon zich authenticeert. 

De directe interactie van de Persoon met de Authorization Service is bedoeld om de PGO Server te autoriseren om de Resource Server aan te spreken. Die levert de uiteindelijke Gegevensdienst pas.

DigiD

Het staat de Authorization Server dus vrij te kiezen tussen het SAML-koppelvlak en het CGI-koppelvlak van DigiD. Wel is het van belang op te merken dat Logius aangeeft dat niet het CGI-koppelvlak, maar het SAML-koppelvlak de toekomst-vaste keuze is (zie paragraaf 2.4.4 van dit document). Mocht DigiD het CGI-koppelvlak gaan afvoeren, raakt dat voor die MedMij-Deelnemers die dat koppelvlak gebruiken ook hun deelname in MedMij.

Het staat de Authorization Server ook vrij om ervoor te kiezen via de Toegangsverleningsservice aan te sluiten op DigiD.

Enkele DigiD-aansluiteisen vragen in de MedMij-context om toelichting.

Ten eerste eist DigiD dat de eindgebruiker “gedurende de gebruikerssessie” de gelegenheid houdt uit te loggen. Voor de UC(I) Verzamelen en UC(I) Delen mag deze “gebruikerssessie” geacht worden zich niet verder uit te strekken dan de Authorization Server. Daarna is immers de Persoon geen “gebruiker” meer van de Authorization Server, maar van de voor DigiD irrelevante PGO Server, die op zijn beurt de (daartoe door Persoon geautoriseerde) gebruiker van de Resource Server is geworden. Tijdens de sessie bij de Authorization Server is er bovendien slechts één eindgebruikersinteractie, namelijk bij het voorleggen van de toestemmings/bevestigingsvraag. Het afwijzen van die toestemming/bevestiging door de Persoon mag worden opgevat als uitloggen. Wanneer de gebruiker vijftien minuten niets doet op het autorisatiescherm, of wanneer de gebruiker dit scherm sluit, moet de sessie beëindigd worden. Er zijn geen verdere uitlogvoorzieningen nodig.

Ten tweede stelt DigiD eisen aan de “DigiD-sessiegegevens” en de daarvan afgeleide gegevens. Dat roept de vraag op om welke gegevens dat gaat en of de authorization code en het access token moeten worden opgevat als afgeleide gegevens. De reden voor deze eis is dat de bedoelde gegevens nodig zijn om weer uit te loggen, vooral in het geval van single sign-on. In UC(I) Verzamelen en UC(I) Delen worden echter geen door DigiD geleverde gegevens, noch daarvan “afgeleide”, voor uitloggen gebruikt. Aan deze eis wordt daarom bij voorbaat voldaan. Wanneer single sign-on ook mogelijk wordt in MedMij, moet dit natuurlijk worden herbezien.

Ten derde eist DigiD dat na de authenticatie wordt geredirect naar hetzelfde domein van waaruit DigiD is aangeroepen. Daaraan wordt sowieso voldaan in het MedMij Afsprakenstelsel, zij het dat deze DigiD-aanroep en -redirect zijn ingebed in een vergelijkbare Oauth-aanroep en -redirect. De situatie is dus genest: de PGO Server roept de Authorization Server aan, die DigiD aanroept, die redirect naar de Authorization Server, die de OAuth-flow vervolgt, waarin onder meer een redirect naar de PGO Server plaatsvindt. Die nesting maakt het weliswaar complexer, maar de conformiteit aan de eis blijft intact.