Document toolboxDocument toolbox

RFC0014 Extra controles door Authorization Interface

Samenvatting

Waarom is deze RFC nodig?

Kwetsbaarheid in OAuth opheffen

Oplossingsrichting

Authorization server extra controle(s) voorschrijven.

Redirect url toevoegen aan OCL en controle hierop voorschrijven.

Aanpassing van

Authorisation interface (AS)

Impact op rollen

DVZA, DVP

Impact op beheer

Geen

Impact op RnA

Schema OCL aanpassen.

Impact op Acceptatie

Ja, controle op redirect url tegen waarde in OCL toevoegen.

Gerelateerd aan (Jira issues)

AF-1131 AF-898 - Getting issue details... STATUS

EigenaarJohan Hobelman, Ron van Holland (Unlicensed)
Implementatietermijn

1.3.0

Motivatie verkorte RFC procedure (patch)

Chipsoft en Nedap:  Verduidelijken hoe om te gaan met onbekende scope parameters

Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Product Owner Stichting MedMij

 

AkkoordProductmanager Beheerorganisatie

 

Akkoord
Adviseur ICT Stichting MedMij

 

AkkoordLeadarchitect Beheerorganisatie

 

Akkoord
Ontwerpteam

 

Akkoord


Deelnemersraadnvt
Eigenaarsraad

Principe's

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Neutraal

11 Stelselfuncties worden vanaf de start ingevuld

Neutraal

2 Dienstverleners zijn transparant over de gegevensdiensten 

Neutraal

12 Het afsprakenstelsel is een groeimodel

Neutraal

Dienstverleners concurreren op de functionaliteiten

Neutraal

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Neutraal

Dienstverleners zijn aanspreekbaar door de gebruiker

Neutraal

14 Uitwisseling is een keuze

Neutraal

De persoon wisselt gegevens uit met de zorgaanbieder

Neutraal

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Neutraal

MedMij spreekt alleen af wat nodig is

Neutraal

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Neutraal

De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

Neutraal

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Neutraal

De dienstverleners zijn deelnemers van het afsprakenstelsel

Neutraal

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Positief

10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling

Neutraal

19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat

Positief

Uitwerking

Te verwerken punten:

  1. Oauth client moet CSRF protection moet: https://auth0.com/docs/protocols/oauth2/oauth-state
  2. AS moet controle op redirect url tegen waarde in OCL uitvoeren. Dus volledige redirect_uri (of lijst met toegestane uri's) opnemen in OCL. redirect_uri wel in authorization request laten, zodat de client eventueel kan kiezen welke uit een geldig lijstje nu te gebruiken. Volledige redirect_uri wordt al vereist in authorization request (1.2.0).
  3. Verduidelijken hoe om te gaan met onbekende scope parameters.



Aanpassen in sectie: Authorization interface

1a. onder tabel toevoegen:

Afhandeling parameters

Conform de OAuth 2- specificatie moeten overige parameters die meegestuurd worden in het request genegeerd worden.


2a. 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.

Slagen niet al deze verificaties, dan behandelt de Authorization Server dit als uitzondering 1a volgens verantwoordelijkheid 6.


2b. Na ontvangst van een authorization request verifieert de Authorization Server dat:

  • deze GegevensdienstId voorkomt bij de betreffende client_id op de OAuth Client List;
  • zij namens deze Zorgaanbieder deze Gegevensdienst ontsluit;
  • indien in de scope ook subscribe voorkomt:
    • bij de betreffende client_id en Gegevensdienst op de OAuth Client List ook een subscription notification endpoint en een resource notification endpoint voorkomen;
    • zij namens deze Zorgaanbieder ook Abonnementen op deze Gegevensdienst ontsluit, blijkens de Zorgaanbiederslijst.

Slagen niet al deze verificaties, dan behandelt de Authorization Server dit als uitzondering 1b volgens verantwoordelijkheid 6.


Verificatie van erkenning op Gegevensdienst

Zo voorkomt de Authorization Server dat gevolg wordt gegeven aan een verzoek dat blijkens de OAuth Client List of Zorgaanbiederslijst niet is toegestaan.


6. Authorization Server en PGO Server behandelen uitzonderingssituaties inzake het authorization interface af volgens onderstaande tabel.

In tabel aanpassen de Melding kolom voor Authorization interface 1b naar:

"conform OAuth 2.0-specificatie, par. 4.1.2.1, met de daar genoemde toepasselijke, zo specifiek mogelijke, error code"



Aanpassen in sectie: Token interface

  1. onder tabel toevoegen:

Afhandeling parameters

Conform de OAuth 2- specificatie moeten overige parameters die meegestuurd worden in het request genegeerd worden.


3a. De OAuth Client biedt een, via de in de authorization request opgenomen redirect_uri, ontvangen authorization code slechts aan aan de Authorization Server indien:

  • de waarde van de, in de authorization response ontvangen, state overeenkomt met de door de OAuth Client zelf gegenereerde state, die werd verzonden in het authorization request.

3b. De OAuth Client biedt een zekere authorization code maximaal eenmaal aan aan de Authorization Server.

3c. De Authorization Server voert een authorization code af, wanneer het eenmaal door een OAuth Client is aangeboden


redirect_uri toevoegen, opties:

  1. DVP introduceren die meerdere OAuthClients mag hebben etc. >> dus grote aanpassing
  2. redirect_uri toevoegen als attribuut van OAuthClient >> meest eenvoudige oplossing
  3. redirect_uri toevoegen als attribuut van InterfaceVersie >> gekozen oplossing
  4. redirect_uri toevoegen als attribuut van Gegevensdienst >> dan analoog aan ontvangst van notificaties, maar dan misschien ook verschillende hostnames moeten kunnen registreren en daarmee wending richting optie 1.

Op pagina /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629422 aanpassen:

  • In het metamodel de klasse “OAuthclientGegevensdienst” te verwijderen.
  • In het metamodel de klasse “OAuthclientInterfaceversie” toe te voegen
  • In het metamodel de associatieklassen van “OAuthclientGegevensdienstInterfaceversie” aan te passen naar “OAuthclientInterfaceversie” en “Gegevensdienst”.
  • In het metamodel de invariant die hangt aan de klasse “OAuthclientGegevensdienst” te wijzigen. (*)
  • In het logisch model met de ‘herkomsttabel’ de verwijzing vanuit “Interfaceversie_OCL” (logisch model) aan te passen naar “OAuthclientInterfaceversie” (metamodel).

Risico's

Deze RFC is bedoeld om bestaande risico's te mitigeren, maar introduceert ook nieuwe dreigingen:

DreigingKansImpactMaatregelen

Meer hack-pogingen op DVP's en DVZA's, want redirect_uri's van DVP's (en daarmee de attack surface) worden publiek voor alle MedMij deelnemers (officieel slechts voor DVZA's)

klein

midden

Bestaande maatregelen om de OAuth-flow zo veilig mogelijk te houden. Bijv. gebruik en controle van state parameter.

Deelnemers verplichten om opgevraagde OCL-gegevens voldoende te beveiligen? Is dit al geborgd in het afsprakenstelsel?

Bijlagen

  File Modified

PNG File RedirectURI.png

Oct 07, 2020 by Arjan van Krimpen

JPEG File Logische model (1.3.0).jpg

Oct 27, 2020 by Arjan van Krimpen