Document toolboxDocument toolbox

MMOS-259, SR - Verheldering scope core.autint.200

Owned by Ibrahim Benyahya, created
Last updated: Jan 08, 2024
3 min read

Omschrijving Changelog, met daarin:

  • Titel Jira ticket

  • Naam te wijzigen pagina

  • Korte omschrijving v.d. aanpassing in voltooid verleden tijd.

Verheldering scope core.autint.200

Authorization interface

Er zijn voorbeelden toegevoegd aan de scope parameter, zodat de opbouw van deze scope duidelijker wordt. Ook is een inconsistentie met betrekking tot de functie Delen aangepast.

Impact op:

DVP
DVA
Geen van beiden

Te informeren Stakeholders

Acceptatie
R&A beheer
Regie
CCDA
Security
Relatiebeheer
Communicatie
MM Loket
Stichting MM

Moeten afbeeldingen/mockups aangepast worden?

Ja
Nee

Aan te passen versies afsprakenstelsel

2.X.Y (waarschijnlijk 2.0.4)

Classificatie

Patch
Minor
Major

Implementatie Termijn

9 januari

Gerelateerde tickets (o.a. ticket van deze ticket)

https://vzvz.atlassian.net/browse/MMOS-259

Status

Staat klaar voor release in afsprakenstelsel
Verwerkt in afsprakenstelsel

Uitwerking

Zet bij de locatie (en indien van toepassing bij de “In te voegen links (optioneel)”) de link naar de confluence space (bijv. MedMij Afsprakenstelsel 2), zet hier niet de link naar scroll view pagina. Is het een tabel benoem dan bij de locatie ook de rij.

Kopieer voor de oude en de nieuwe tekst ook de regel voor en na de aan te passen zin.

In de kolom “Oude tekst”, maak de verwijderde of gewijzigde stukken rood en streep ze door
In de kolom “Nieuwe tekst”, geef de nieuwe stukken hebben deze blauwige/groenige kleur.

Wil je een link toevoegen maak het woord paars in de kolom “Nieuwe tekst” en zet de link in de kolom “In te voegen links (optioneel)”.

Door te voeren wijzigingen

Locatie

https://afsprakenstelsel.medmij.nl/asoptioneel/mmoptioneel/authorization-interface#core.authint.200

Oude tekst

De onderstaande parameters in de authorization request zijn verplicht en moeten als volgt gevuld worden.

parameter

vulling

toelichting

parameter

vulling

toelichting

response_type

letterlijke waarde code

Dit is het gevolg van verantwoordelijkheid core.autorisatie.201.

client_id

de hostname, die in de OAuth Client List is opgenomen, van de Node van de OAuth Client die de authorization request doet

 

redirect_uri

  1. zodanig dat de erin opgenomen hostname gelijk is aan de client_id en er geen poortnummer is opgenomen

  2. de redirect_uri moet volledig zijn en verwijzen naar een https-beschermd endpoint

  3. de redirect_uri moet urlencoded zijn (conform RFC 3986)

Zie verantwoordelijkheden core.adressering.200, core.adressering.201 en core.adressering.202.

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 Gegevensdienst 53 bij eenofanderezorgaanbieder@medmij;

  • "eenofanderezorgaanbieder~53 eenofanderezorgaanbieder~57, voor het eenmalig afnemen van Gegevensdiensten 53 en 57 bij eenofanderezorgaanbieder@medmij.

Opmerking voor publicatieteam: het volledige tweede punt dient verwijdert te worden.

state

  1. conform sectie 4.1.1. van RFC 6749. 

Hiermee geeft de OAuth Client informatie mee aan de OAuth 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).

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

Nieuwe tekst

De onderstaande parameters in de authorization request zijn verplicht en moeten als volgt gevuld worden.

parameter

vulling

toelichting

parameter

vulling

toelichting

response_type

letterlijke waarde code

Dit is het gevolg van verantwoordelijkheid core.autorisatie.201.

client_id

de hostname, die in de OAuth Client List is opgenomen, van de Node van de OAuth Client die de authorization request doet

 

redirect_uri

  1. zodanig dat de erin opgenomen hostname gelijk is aan de client_id en er geen poortnummer is opgenomen

  2. de redirect_uri moet volledig zijn en verwijzen naar een https-beschermd endpoint

  3. de redirect_uri moet urlencoded zijn (conform RFC 3986)

Zie verantwoordelijkheden core.adressering.200, core.adressering.201 en core.adressering.202.

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 Gegevensdienst 53 bij eenofanderezorgaanbieder@medmij;

state

  1. conform sectie 4.1.1. van RFC 6749. 

Hiermee geeft de OAuth Client informatie mee aan de OAuth 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).

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://medmij.deenigeechtepgo.nl &scope=eenofanderezorgaanbieder &state=xcoivjuywkdkhvusuye3kch CUSTOM HEADERS: X-Correlation-ID: c0e7b545-9606-4eef-bea7-75d8addaa54b MedMij-Request-ID: 57510be1-73e6-4a75-9db8-ee005cced48f

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.

 

In te voegen links

Review

Zijn de volgende acties uitgevoerd?

Alle rijen in de tabel zijn ingevuld
Er staan geen taal- en spelfouten in de aanpassingen
De juiste locatie is ingevoerd
(Indien van toepassing) de link(s) is/zijn correct toegevoegd
(Indien van toepassing) de vereiste afbeeldingen zijn aangepast