MO-52 Logvelden Bijlage 4
- Kailesh Bansi (Deactivated)
- Casper van der Harst
- Marlotte Pannekoek
1. Inhoudsopgave
2. Probleembeschrijving
In het vooronderzoek zijn verschillende knelpunten benoemd op het gebied van signaleren, melden, analyseren en oplossen van verstoringen. Er is dus onvoldoende inzicht in verstoringen, zie hoofdstuk 2 Probleembeschrijving van het Vooronderzoek die gedeeld is met de RFI voor een uitgebreide analyse van het probleem.
Om verstoringen sneller te kunnen signaleren en melden is centrale monitoring van de gegevensuitwisseling tussen schakels in de MedMij keten benoemd als de gewenste oplossingsrichting. Dit document bevat het voorstel van de loggegevens die nodig zijn van de verschillende schakels in de MedMij keten, om deze centrale monitoring goed te kunnen doen. Concreet wordt in dit document de vraag beantwoord:
Welke loggegevens zijn nodig bij welke gegevensuitwisseling van welke deelnemer voor centrale monitoring van verstoringen in de MedMij keten?
3. Aanpak
Na het vooronderzoek en de expertsessie met deelnemers afgelopen 15 februari wordt de oplossing verder uitgewerkt in 2 delen:
Specificatie van loggegevens die door deelnemers gedeeld gaan worden voor centrale monitoring. Uitvoering door Kailesh, Marlotte, Floor
Opstellen van business requirements en selectie van ICT-oplossing voor het uitvoeren van de ketenmonitoring. Nog te bepalen
In dit document wordt gewerkt aan deel 1 volgens onderstaand stappenplan (afgestemd met Jeroen 21/2)
Voorstel maken van de loggegevens die door deelnemers moeten worden gedeeld. Daarnaast hoe de beschikbaarheid van deelnemers gecontroleerd wordt middels ping-functie
Checken intern met juristen (Geranne, Jacqueline) en andere intern betrokkenen of voorstel voldoet aan eerder gestelde randvoorwaarden rondom dataproportionaliteit, niet delen van concurrentie-gevoelige data en aan wetgeving, zie ook hfst 6.
Voorstel voorleggen aan deelnemers in een volgende expertsessie
De planning is om de benodigde aanpassingen in het afsprakenstelsel in de release van mei mee te nemen en in oktober verplicht te stellen. De uitbreiding van de managementrapportages op basis van de loggegevens, wordt pas na oktober gedaan.
Buiten scope
In dit document zijn de loggegevens uitgewerkt die deelnemers gaan delen wanneer zij Lijsten ophalen bij de MedMij Stelselnode en wanneer Personen gegevens gaan Verzamelen. De loggegevens voor het Delen van gegevens door Personenen of voor Abonneren/notificeren zijn niet opgenomen in dit document. Het voorstel is om deze in een latere fase uit te werken.
Log-gegevens die aanvullend gedeeld moet worden door deelnemers bij gebruikmaking van Langdurige Toestemming zijn ook niet opgenomen. Want Langdurige Toestemming wordt op dit moment nog uitgewerkt.
Definitie van de ketennorm met betrekking tot beschikbaarheid, kwaliteit van gegevensuitwisseling, etc. is ook buiten scope. Ketennormen worden in een volgende fase uitgewerkt.
4. Openstaande vragen
Omdat MedMij berichten over het openbare internet gaan is het ontwerp van MedMij erop gericht zo min mogelijk informatie toe te voegen over een FHIR code aan een bericht. Hoe hiermee om te gaan?
5. Uitgangspunten
De loggegevens worden vastgelegd volgens JSON-specificaties. Dit moet nog wel uitgewerkt worden door solution architect. FHIR is de andere optie. Echter FHIR wordt alleen in het Zorgdomein gebruikt en niet in andere domeinen. Daarom is niet voor FHIR gekozen maar voor JSON.
6. Uitwerking loggegevens
6.1. Overzicht van de transacties
De grijze bolletjes worden gelogd door de DVP, de blauwe bolletjes door de DVA en de groene bolletjes door MedMij zelf.
Afhankelijk van of de beschikbaarheidstoets laat of vroeg plaatsvindt worden de bolletjes 8 & 9 of 20 & 22 overgeslagen.
De groene bolletjes hebben letters in plaats van nummers, omdat deze het ophalen van de lijsten betreft. Deze lijsten dienen als voorbereiding worden opgehaald.
Het voorstel is dat van alle genummerde bolletjes de loggegevens gedeeld worden door deelnemers. Een toelichting van de bolletjes en lijntjes staat in onderstaande tabel:
Nummers | Naam | Van- Naar | Toelichting (bron MedMij afsprakenstelsel Verzamelen) | Nog openstaande vragen |
|---|---|---|---|---|
A t/m I | Ophalen lijsten | DVP- MedMij Stelselnode en andersom DVA- MedMij Stelselnode en andersom | De DVP vraagt de ZAL (Aanbiederslijst), GNL (Gegevensdienstnamenlijst) of WHL (Whitelist) op, en de MedMij Stelselnode stuurt deze terug De DVA vraag de GNL, WHL of OCL (OAuth Client List) op en de MedMij Stelselnode stuurt deze terug. | |
1 | Authorization Request verstuurd | User Agent naar DVA | De User Agent verstuurt een authorization request naar de Authorization Server van de DVA. Het adres van het authorization endpoint komt uit de ZAL. Het authorization request mag desgewenst, onder voorwaarden, meerdere Gegevensdiensten van de Aanbieder bevatten. | |
2 | Authorization Request ontvangen | User Agent naar DVA | De Authorization server van de DVA ontvangt het Authorization request. | |
3 | Tonen MedMij Landingspagina | DVA naar User agent | De Authorization server van de DVA heeft het Authorization request ontvangen. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren en presenteert de landingspagina. |
|
4 | Redirection naar Authentication server | User Agent naar DigiD | Dan start de Authorization Server van de DVA (nu in de rol van Authentication Client) de authenticatieflow door de User Agent naar de Authentication Server te redirecten. Dit gebeurt onder meegeven van een | |
Redirection naar Inlogpagina | DigiD naar User Agent | |||
Inloggen | User Agent naar DigiD | De Authentication Server vraagt de Persoon via zijn User Agent om inloggegevens. | ||
Redirection naar Authorization server (SAML artifact) | DigiD naar User Agent | Wanneer de inloggegevens juist zijn, redirect de Authentication Server de User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs.
| Klopt het dat de redirection van DigiD naar de DVA verloopt via de User Agent? | |
5 | Ga naar redirect_uri DVA (SAML artifact) | User Agent naar DVA | Gebeurt een eventuele nieuwe inlogpoging onder dezelfde Sessie ID van de DVA Authorization server? | |
6 | Artifact resolution (SAML artifact) | DVA naar DigiD | Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op. | |
7 | Artifact response (SAML assertion) | DigiD naar DVA | Verzonden Authorization response van DigiD naar DVA | |
8 | Vroege beschikbaarheidstoets opgevraagd | DVA naar DVA | Bij een vroege beschikbaarheidstoets wordt voorafgaand aan het resource request gecontroleerd of er Gegevensdienst voor uitwisseling beschikbaar is. Hierbij wordt het opvragen van de beschikbaarheid gelogd. | |
9 | Vroege beschikbaarheidstoets antwoord | DVA naar DVA | De ontvangst van het antwoord wordt ook gelogd. | |
10 | Tonen Toestemmingspagina | DVA naar User Agent | Indien de Aanbieder kan instaan voor de beschikbaarheid van tenminste één Gegevensdienst, of wanneer géén gebruik wordt gemaakt van dit vroegste moment van de beschikbaarheidstoets, dan presenteert de Authorization Server via de User Agent aan Persoon in een Toestemmingsverklaring, de vraag of Persoon de Aanbieder toestaat de gevraagde persoonlijke gezondheidsinformatie aan de DVP Server (als OAuth Client) te sturen. Indien op dit moment al bekend is dat een bepaalde Gegevensdienst niet beschikbaar is voor de Persoon, dan mag deze niet worden opgenomen in de Toestemmingsverklaring. | |
11 | Toestemming geven | User Agent naar DVA | Toestemming wel/niet ontvangen. | |
12 | Redirection naar DVP server (Authorization response, OAuth authorization code) | DVA naar User agent | Bij akkoord logt de Authorization Server dit als toestemming, genereert een authorization code en stuurt dit als ophaalbewijs, door middel van een User Agent redirect met de in het authorization request ontvangen De Authorization Server stuurt daarbij de local state-informatie mee die hij in het authorization request van de DVP Server heeft gekregen. Laatstgenoemde herkent daaraan het verzoek waarmee hij de authorization code moet associëren. De DVP Server vat niet alleen deze authorization code op als ophaalbewijs, maar leidt er ook uit af dat de toestemming is gegeven en logt het verkrijgen van het ophaalbewijs. | |
13 | Ga naar redirect URI DVA (SAML-artifact) | User agent naar DVP | ||
14 | Token request sent | DVP naar DVA | Met dit ophaalbewijs wendt de DVP Server zich weer tot de Authorization Server, maar nu zonder tussenkomst van de User Agent, voor een access token. | |
15 | Token request received | DVP naar DVA | Acces token request ontvangen. | |
16 | Token response sent | DVA naar DVP | Daarop genereert de Authorization Server een access token en stuurt deze naar de DVP Server. | |
17 | Token response received | DVA naar DVP | DVA token response ontvangen. | |
18 | Resource request sent | DVP naar DVA | Nu is de DVP Server gereed om één of meerdere verzoeken om de gezondheidsinformatie naar de Resource Server te sturen, nadat hij de Persoon eventueel nog nadere keuzes heeft laten maken. Het adres van de juiste resource endpoints haalt hij uit de Aanbiederslijst. Hij plaatst telkens het access token in het bericht en zorgt ervoor dat in het bericht geen BSN is opgenomen. | |
19 | Resource request received | DVP naar DVA | DVA heeft het resource request van DVP ontvangen. De Resource Server controleert bij ieder verzoek of het ontvangen token recht geeft op de gevraagde resources en haalt deze (al dan niet) bij achterliggende bronnen op. | |
20 | Late beschikbaarheidstoets verstuurd | DVA naar DVA | DVA beschikbaarheidsverzoek verstuurd | |
21 | Late beschikbaarheidstoets ontvangen | DVA naar DVA | DVA beschikbaarheidsverzoek antwoord is ontvangen. De Resource Server controleert bij ieder verzoek of het ontvangen token recht geeft op de gevraagde resources en haalt deze (al dan niet) bij achterliggende bronnen op. Dan breekt het uiterste moment aan waarop de Resource Server ervoor moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft. | |
22 | Verzamelen gegevens verzonden | DVA naar DVA | ||
23 | Verzamelen gegevens ontvangen | DVA naar DVA | Is de Gegevensdienst beschikbaar, dan verstuurt de Resource Server deze ze in een resource response naar de DVP Server. | |
24 | Resource response sent | DVA naar DVP | ||
25 | Resource response received | DVA naar DVP | DVP Resource Response ontvangen. De DVP Server bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. De DVP Server bevraagt de Resource Server daarna mogelijk opnieuw, eventueel na nieuwe interactie met de Persoon. Zolang het access token geldig is, kan dat. |
6.2. Te loggen variabelen
Variabele | Toelichting | Waarom belangrijk | Voor welke transacties (zie tabel paragraaf 4.1) | Voor welke meetpunten /indicatoren (NOG IN TE VULLEN) | Opmerkingen/vragen |
|---|---|---|---|---|---|
InterfaceversieID | De identifier van de interfaceversie. String van minimaal één en maximaal 30 tekens. Interfaces zijn geversioneerd: verschillende versies van interfaces kunnen tegelijkertijd op het MedMij-netwerk worden aangeboden. Daarom is er de klasse Interfaceversie in het modelgebied Changes. Alle endpoints in de Zorgaanbiederslijst en Oauth Client List (zie onder) horen bij één Interfaceversie. | Dit is belangrijk voor foutopsporing. Want een versie verschil kan verstoringen in de gegevensuitwisseling tussen deelnemers veroorzaken. | Alle | ||
Versie van de opgehaalde lijsten (ZAL, OCL, WHL, GNL) | De versie van de lijsten die een deelnemer ophaalt bij de MedMij Stelselnode | Zie boven | A t/m I | ||
Type en versie PGO | Webapp of app en het OS gelogd te worden | Foutopsporing. Fouten komen soms alleen in de webinterface voor. Of niet in de app van Apple, maar wel in de app van Android | Voorstel: Alle logmomenten van de DVP of User Agent. Dit zijn: 1,4, 13,14,17,18,25? | Moet ook de gebruikte browser gelogd worden door de PGO-gebruiker bij Webapp? | |
Naam en gebruikte versie van de DVA | Naam van de DVA applicatie en de gebruikte versie | Foutopsporing | Voorstel: Alle logmomenten van de DVA Agent. Dit zijn: 2,3, 5 t/m 7, 10 t/m 12, 15, 16, 19 t/m 24 | ||
Naam en gebruikte versie van bronsysteem van de Zorgaanbieder | Naam van bronsysteem die de Zorgaanbieder gebruikt en de gebruikte versie | Foutopsporing | Voorstel: Alle mogelijke momenten van gegevensuitwisseling tussen DVA en bronsysteem Zorgaanbieder. Dit zijn: 8,9 20 t/m 23 | Kan dit? Of moet eerst de Zorgaanbieder deelnemer zijn in het afsprakenstelsel? | |
Trace ID voor gegevensuitwisseling in de MedMij-keten voor Verzamelen of Delen | Een Trace-ID is een uniek ID om de gegevensuitwisselingen over alle schakels in de MedMij keten te kunnen volgen, van Authorization Request (1) naar de uiteindelijke Resource response(s) (19) De DVP stuurt een Trace-ID mee bij het versturen van het verzoek voor het verzamelen of delen van gegevens naar een DVA. Dit Trace-ID wordt door alle schakels in de MedMij-keten vervolgens opgenomen in de logging van de gegevensuitwisselingen die volgen op het verzoek van de DVP. | Een Trace ID in de logging is belangrijk om de kwaliteit van de gegevensuitwisseling in de gehele MedMij keten te kunnen bepalen. Zoals het aantal succesvolle en niet succesvolle opvragingen in de gehele MedMij keten. Daarnaast voor foutopsporing wanneer melding wordt gedaan van verstoringen. | 1 t/m 25 | ||
Trace ID voor het ophalen van lijsten door deelnemers bij de MedMij Stelselnode | Er wordt ook een Trace-ID meegestuurd vanuit de DVP en DVA naar de MedMij StelselNode bij het ophalen van de lijsten (ZAL, WHL, etc). Dit Trace-ID wordt door de MedMij-Stelselnode vervolgens ook opgenomen in de logging, in de opvolgende transacties. | Zie boven | A t/m I | ||
Authorization request ID | Identifer van de authorization request. Dt is het huidige MedMij-request-ID, zie link naar betreffend onderdeel in Afsprakenstelsel. Met dit ID kan de gegevensuitwisseling na de authorization request tot de authorization response gevolgd worden over de schakels. |
| 1 t/m 13? | ||
Token request ID | Identifer van de token request. Met dit ID kan de gegevensuitwisseling na de token request tot de token response gevolgd worden over de schakels. |
| 14 t/m 16 | Zie boven | |
Resource request ID | Identifer van de resource request. Met dit ID kan de gegevensuitwisseling na de resource request tot de resource response gevolgd worden over de schakels. |
| 18 t/m 25? | Er is een al een MedMij-request-ID beschikbaar, die gelogd wordt door een DVA bij het verzenden en ontvangen van resource requests zie link naar betreffend onderdeel in Afsprakenstelsel. Deze informatie is nu opgehaald over de het MedMij-request-ID. Het MedMij-request-ID is (na een RFC ingediend door Maarten Schmidt in 2019-2020) geïmplementeerd door een DVA in geval van een resource request richting een Zorgaanbieder. (De aanleiding voor deze RFC was een security incident). | |
Event DateTime | Datum en tijdstip van het verzenden of ontvangen van het bericht. Gewenst is dat deelnemers een datum en tijdstip vast leggen tot op de milliseconde. Het afsprakenstelsel schrijft het volgende voor over synchronisatie van de gebruikte klok, zie [1] "De klokken van IT componenten die communiceren via MedMij en logging in het kader van MedMij bijhouden, MOETEN worden gesynchroniseerd met pool.ntp.org. Het is toegestaan te synchroniseren met een alternatieve NTP-server, wanneer maatregelen zijn getroffen om de afwijking met pool.ntp.org niet groter dan plus of min 500 ms te laten zijn." | Event_DateTime van de gegevensuitwisselingen zijn nodig om de doorlooptijden van een transactie te meten. Een grote doorlooptijd kan wijzen op een verstoring of een (poging tot) hacking. | Alle | Niet alle deelnemers leggen de timestamp vast volgens dezelfde klok. | |
Deelnemer ID | De gebruikte identifier van de deelnemer (DVP of DVA) binnen het MedMij afsprakenstelsel. Dit is een string van minimaal één en maximaal 30 tekens, zie /wiki/spaces/MMVerplicht/pages/132023555 | Het deelnemer ID is nodig om de kwaliteit en trends in gegevensuitwisseling per deelnemer of per combinatie van deelnemers te kunnen bepalen. Daarnaast voor foutopsporing. Tenslotte voor het testen van de bereikbaarheid per deelnemer | Alle | Dit is het koppelvlak richting CMS systeem van allsolutions. Zorgen dat we daar hetzelfde ID hebben | |
Deelnemer FQDN | De fully-qualified domain name van een deelnemer conform RFC3696, sectie 2. Zie ook /wiki/spaces/MMVerplicht/pages/132023613 | Zie boven | Alle | ||
Zorgaanbieder ID | De gebruikte identifier van een Zorgaanbieder binnen het MedMij afsprakenstelsel. | Zie deelnemer ID | 1 t/m 25? | Dit is een belangrijk koppelvlak richting de R&A bron | |
Zorgaanbieder FQDN | De fully-qualified domain name van een Zorgaanbieder | Zie boven. | 1 t/m 25? | ||
Lijst ID | Identifier van een lijst (ZAL, WHL, OCL, GNL) | Het lijst ID is nodig om de kwaliteit en trends in gegevensuitwisseling per lijst te kunnen bepalen. Daarnaast voor foutopsporing | A t/m I | ||
Lijst FQDN | De fully-qualified domain name van de lijsten (ZAL, WHL, OCL, GNL) | Zie boven | A t/m I | Is Lijst FQDN de juiste term? | |
Sessie ID | Een Sessie ID knoopt meerdere handelingen van één persoon bij dezelfde applicatie aan elkaar. Bijvoorbeeld meerdere resource requests bij de DVP. Of meerdere pogingen tot inloggen bij de Authorization Server van de DVA | Een sessie ID kan helpen bij foutopsporing. Bijvoorbeeld om te bepalen of een hoge frequentie van foutmeldingen veroorzaakt wordt door dezelfde gebruiker of verschillende gebruikers | 1,4, 18,19? | ||
Gepseudonimiseerd user- ID? | Dit betreft een random nummer wat toegekend wordt door een deelnemer aan een gebruiker. Dit nummer heeft geen correlatie met het BSN en betreft een niet-traceerbaar-ID. Maar met dit nummer is wel te achterhalen of dezelfde gebruiker een actie uitvoert bij een deelnemer of een andere gebruiker Momenteel maken DVP's gebruik van een User-ID. Dit zorgt ervoor dat zij meerdere gestarte sessies van gebruikers binnen een paar milliseconden van elkaar kunnen onderscheiden. | Met name om te zien of het gebruikers terugkeren of eenmalig het PGO gebruiken. Inzicht in of het de gebruiker uiteindelijk lukt om gegevens op te halen (ondanks mogelijk meerdere verschillende verzoeken) | Aantal unieke gebruikers over tijd | Is dit nodig, als er ook een sessie-ID wordt vastgelegd? Nog te bespreken of dit wel wenselijk is vanuit privacy oogpunt | |
Gegevensdienst ID | Identifier van de gegevensdienst(en) die onderdeel zijn van de gegevensuitwisseling. He ID geeft aan welke gegevensdienst het is en welke versie. |
| 1 t/m 25? | ||
Resource ID | Identifier van de verstuurde of ontvangen resources. De identifier geeft het type resource aan. | 18 t/m 25? | |||
De omvang van het bericht | Grootte van het bericht (aantal bits) |
| Alle? | ||
Soort bericht | Twee soorten berichten van deelnemers worden onderscheiden. Berichten waarin de logging van events staan en berichten met het resultaat van een ping op bereikbaarheid, zie hoofdstuk 6. | Alle? | |||
Resultaat (Succes of Foutcodes) | Bij de verschillende gegevensuitwisselingen in de MedMij keten (de authorization request en response, token request en response en resource requests en response) kunnen er fouten optreden Gewenst is om foutcodes voor een aantal veelvoorkomende fouten te delen in de logging van de deelnemers. | Foutopsporing | Alle, de mogelijke foutcodes verschillen echter per gegevensuitwisseling | Nog te bepalen welke foutcodes per type gegevensuitwisseling (de authorization request en response, token request en response en resource requests en response gedeeld moeten worden in de logging. De foutcodes volgens OAuth 2.0 staan uitgewerkt in MO-39 Duiding van errors. Zie daarnaast hoofstuk 6 | |
Status langdurige toestemming | Dit is voor de toekomst. De status van langdurige toestemming die een PGO-gebruiker heeft gegeven per Zorgaanbieder per gegevensdienst. De status kan zijn: Geen toestemming of wel toestemming. | Te bespreken met Casper: kan hierover al iets opgenomen worden in de loggegevens? | |||
Aanvullingen? |
6.3. Indicatoren voor dashboard gebaseerd op ruwe data
De onderstaande tabel logt de volgende variabelen standaard bij elke indicator: ID, FQDN Deelnemers en Zorgaanbieder Event DateTime, Trace-ID. De inhoud van deze tabel moet nog verder uitgewerkt worden. Ntb wie dit gaat doen Wouter, Jennifer en/of Kailesh, Marlotte, Floor.
Indicator | Definitie | Interfaces | Benodigde loggegevens | Bepalen per | Doelen |
|---|---|---|---|---|---|
Aantal succesvolle en niet succesvolle opvragingen | Aantal succesvolle en niet succesvolle opvragingen binnen een bepaald tijdsbestek, die leiden tot:
| 1 - Authorization request 25-Resource response | ID gegevensdiensten Type (ID) opgevraagde resources Type (ID) ontvangen resources Resultaat (succes, of foutcode) | Succesvol en onsuccesvol in percentages en absolute aantallen:
Daarnaast per combinatie van variabelen. Bijvoorbeeld aantal succesvolle opvragingen voor alle gegevensdiensten voor deze combinatie van DVP en DVA | Er is nu onvoldoende inzicht in de kwaliteit van de gegevensuitwisseling in de gehele MedMij keten, zie knelpunt A hfdst 2 uit het Vooronderzoek Voor inzicht in de kwaliteit van de keten is inzicht in het resultaat van de totale aantal opvragingen in de gehele MedMij keten gewenst. |
Aantal succesvolle en onsuccesvolle Authorization requests van DVP naar DVA | Aantal succesvolle en niet succesvolle authorization requests binnen een bepaald tijdsbestek van DVP naar DVA | 1 - Authorization request 13 - Authorization response | Sessie ID Resultaat (succes, of foutcode) | Succesvol en onsuccesvol in percentages en absolute aantallen:
en combinaties hiervan Daarnaast is voor de onsuccesvolle authorization requests waarschijnlijk een onderverdeling naar foutcode gewenst (verder te bepalen) zoals:
| Voor inzicht in de kwaliteit van de keten is inzicht in de gegevensuitwisseling per interface zoals de Authorization interface gewenst, zie ook doel bij Geslaagde aantal opvragingen Daarnaast voor inzage in eventuele verstoringen bij deelnemers bij de Authorization interface, zie ook knelpunt C in hfdst 2 uit het Vooronderzoek. En voor het sneller kunnen achterhalen van de bron en oorzaak van een verstoring, zie ook knelpunt D in hfdst 2 uit het Vooronderzoek. |
Aantal succesvolle en onsuccesvolle DigiD authenticatie | Aantal succesvolle en onsuccesvolle DigiD authenticaties binnen een bepaald tijdsbestek | 4,5,6,7? | Sessie ID Resultaat (succes, of foutcode). Bijvoorbeeld SAML-Assertion: Succes, Authnfailed, NoAuthncontext, RequestDenied, evt. Abandoned | Resultaten SAML
Daarnaast is voor de onsuccesvolle authenticaties waarschijnlijk een onderverdeling naar oorzaak/foutcode gewenst (verder te bepalen) zoals:
| Zie doelen 'Geslaagde Authorization requests DVP naar DVA' Inzicht krijgen in de authenticatie per DVA en overall om te achterhalen of alleen een specifieke DVA een verstoring ervaart bij de DigiD-authenticatie. Of dat de verstoring ligt bij DigiD en alle DVA's een verstoring ervaren. |
Aantal succesvolle en onsuccesvolle Token requests | Aantal succesvolle en onsuccesvolle DigiD token requests binnen een bepaald tijdsbestek | 14 t/m 17 | Gegevensdienst ID Sessie ID Resultaat (succes, of foutcode). | Succesvol en onsuccesvol in percentages en absolute aantallen:
Daarnaast is voor de onsuccesvolle Token requests waarschijnlijk een onderverdeling naar oorzaak/foutcode gewenst (verder te bepalen) zoals:
| Zie doelen 'Geslaagde Authorization requests DVP naar DVA' |
Aantal succesvolle en onsuccesvolle Resource requests DVA-DVP | Aantal succesvolle en onsuccesvolle Resource requests van DVA-DVP binnen een bepaald tijdsbestek | 13 - 14, 17-18 | Gegevensdienst ID Resource ID Sessie ID Resultaat (succes, of foutcode). | Succesvol en onsuccesvol in percentages en absolute aantallen:
En combinaties hiervan Daarnaast is voor de onsuccesvolle Resource requests waarschijnlijk een onderverdeling naar oorzaak/foutcode gewenst (verder te bepalen) zoals:
| Zie doelen 'Geslaagde Authorization requests DVP naar DVA' |
Aantal succesvolle en onsuccesvolle Resource requests XIS-DVA | Aantal succesvolle en onsuccesvolle Resource requests van XIS-DVA binnen een bepaald tijdsbestek | 15, 16 | Gegevensdienst ID Resource ID Sessie ID Resultaat (succes, of foutcode). | Zie 'Aantal succesvolle en onsuccesvolle Resource requests DVA-DVP' | Zie doelen 'Geslaagde Authorization requests DVP naar DVA' |
Doorlooptijden van de start van een opvraging in een PGO en ontvangst van het antwoord in de PGO | 1 en 14 | Gemiddeld, minimum en maximum doorlooptijd
| Er is nu geen inzage in reactietijden van de schakels in de MedMij keten, zie knelpunt E hfdst 2 uit het Vooronderzoek. Dit is wel gewenst. | ||
Doorlooptijden per interface | |||||
Aantal verstoringen per interface en de duur van de verstoring | Nog verder te bepalen | ||||
Na constatering verstoring: prioritering van de verstoring | |||||
Oplostijden per verstoring | Nog verder te bepalen |
Voor prioritering van de verstoring:
| |||
Welke schakel(s) in de keten de bron zijn van de verstoring | |||||
Signaleren van veiligheids-risico's | |||||
Toename/afname gegevensuitwisselingen in de gehele MedMij Keten | |||||
Toename/afname gegevensuitwisselingen per interface |
6.4. Aandachtspunten
Logging van synchrone en asynchrone gegevensuitwisseling
Wanneer een transactie wordt afgebroken, krijgt een Persoon in sommige gevallen een nieuwe mogelijkheid om alsnog de transactie te vervolgen. Bijvoorbeeld Wanneer de Persoon de authenticatie heeft afgebroken geeft de Dienstverlener aanbieder de mogelijkheid alsnog te authenticeren of de flow af te breken, zie MedMij afsprakenstelsel /wiki/spaces/MMVerplicht/pages/132023131
1:N relatie tussen verzoek van DVP voor verzamelen van gegevens en transacties. De scope bij één Zorgaanbieder kan zijn één of meerdere gegevensdiensten. Daarnaast kunnen voor één gegevensdienst één of meerdere resources worden opgehaald.
Wanneer in de toekomst gebruik gemaakt wordt van Langdurige Toestemming bij een Zorgaanbieder wordt niet langer via DigiD ingelogd voor het verzamelen van gegevens.
7. Foutcodes en foutomschrijvingen
Onderstaande foutcodes zijn op basis van OAuth 2.0 en DigiD (SAML-resultcodes). Dit staat ook in het afsprakenstelsel onder Authorization interface, Token interface, Resource interface, behalve het SAML deel.
7.1. OAuth 2.0 foutcodes
Onderstaand staan de fouten die kunnen optreden bij de verschillende interfaces volgens OAuth 2.0.
Het verzoek vanuit de User Agent richting de AS van Deelnemer Aanbieder op het Authorization interface.
Error Response | Error code |
|---|---|
HTTP 400 (Bad Request) | invalid_request |
invalid_client | |
invalid_grant | |
unauthorized_client | |
access_denied | |
unsupported_response_type | |
invalid_scope | |
HTTP 404 (Not Found) |
Het verzoek vanuit de DVP server richting de AS van Deelnemer Aanbieder voor het ophalen van de access token bij de token interface.
Error Response | Error code |
|---|---|
HTTP 400 (Bad Request) | invalid_request |
invalid_client | |
invalid_grant | |
unauthorized_client | |
HTTP 401 (Unauthorized) |
Het verzoek door de DVP server bij de resource server voor het ophalen van de resources met het verkregen access token
Error Response | Error code |
|---|---|
HTTP 400 (Bad Request) | invalid_request |
HTTP 401 | invalid_ |
HTTP 403 |
|
|
7.2. DigiD foutcodes
De authenticatie bij DigiD voor het ophalen van het SAML artifact kan leiden tot verschillende foutcodes. Deze SAML-foutcodes worden gecommuniceerd naar de DVA.
De foutcodes die kunnen voorkomen zijn:
urn:oasis:names:tc:SAML:2.0:status:AuthnFailed | Wanneer de eindgebruiker het inloggen annuleert. |
urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext | Wanneer de eindgebruiker niet kan voldoen aan het gevraagde betrouwbaarheidsniveau. |
urn:oasis:names:tc:SAML:2.0:status:PartialLogout | Wanneer de eindgebruiker niet uitgelogd kan worden bij alle dienstaanbieders (Bijv. als een dienstaanbieder niet reageert). |
urn:oasis:names:tc:SAML:2.0:status:RequestDenied | Een SAML-responder die weigert een berichtuitwisseling met de SAML-aanvrager uit te voeren moet een reactie bericht geven met een deze foutcode. |
8. Uitwerking ping-functie
De ping-functie wordt in gebruik genomen om te kunnen testen of de servers van de aangesloten partijen bereikbaar zijn. Hierbij is geen inzage in eventuele fouten, maar wel of verkeer mogelijk is richting de servers. Door het pingen kunnen evt. verstoringen/fouten voor de Persoon worden voorkomen bijvoorbeeld een HTTP404, daarnaast heeft de ping-functie ook als voordeel de bereikbaarheid te testen van partijen die niet of nauwelijks verkeer hebben. De ping-functie is nodig als MedMij Regie richting een ketennorm streeft (bereikbaarheid icm kwaliteit van opvragingen).
8.1. MedMij stelselnode
De deelnemers halen ieder kwartier de MedMij-lijsten op bij 'Registratie' van de MedMij stelselnode. De inhoud van deze lijsten is gevuld door de deelnemers bij 'Administratie' van de MedMij stelselnode. Het afsprakenstelsel geeft momenteel aan dat 'MedMij Beheer laat, na het niet beschikbaar raken van bedoelde aandeel, maximaal acht uren (480 minuten) verstrijken voordat het weer beschikbaar is.' Om tijdig de onbereikbaarheid te kunnen achterhalen is het van belang beide onderdelen te pingen.
8.2. Medmij naar DVP
Het is goed om inzage te krijgen in de bereikbaarheid van alle DVP's om daarmee het streven van de IZA te kunnen bereiken om te kunnen voorzien van een PGO voor een ieder die er behoefte aan heeft. Op basis van de DAP en de oplostijden horend bij de prioriteiten is het voorstel ieder kwartier de DVP's te pingen.
8.3. MedMij naar DVA
Een ping is nodig richting de DVA's voor de bereikbaarheid en mogelijke verklaring van verstoringen. Op basis van de DAP en de oplostijden horend bij de prioriteiten is het voorstel de DVA's ieder kwartier te pingen.
8.4. DVA naar Zorgaanbieder
Van de DVA's wordt verwacht dat zij de Zorgaanbieders gaan pingen. Dit zorgt voor inzage in de bereikbaarheid van Zorgaanbieders waarmee weinig verkeer is, als gevolg kunnen deze Zorgaanbieders op een blacklist komen. De blacklist kan gebruikt worden om de Persoon te informeren over onbeschikbaarheid van de geselecteerde Zorgaanbieder. Op basis van de DAP en de oplostijden horend bij de prioriteiten is het voorstel ieder kwartier de Zorgaanbieders te pingen.
8.5. DigiD beschikbaarheid inzichtelijk via storingsmeldingen van DigiD
Er is een app aanwezig genaamd eFlash waarmee er inzage is in de beschikbaarheid van een ToegangVerleningsservice (waaronder eHerkenning en DigiD) : https://apps.dictu.nl/eflash. Daarnaast is het niet toegestaan om DigiD te pingen.
9. Randvoorwaarden
Nr | Randvoorwaarde | Toelichting | Wordt aan deze randvoorwaarde voldaan? Dit wordt gecheckt nadat hfst 3 en 4 zijn uitgewerkt met Geranne, Jacqueline, kernteam, etc. |
1. | Er worden geen persoonsgegevens gedeeld alleen transactiegegevens. | Voor ketenmonitoring zijn transactiegegevens voldoende. Vanuit de DVP's en DVA's wordt verder het aantal unieke accounts aangeleverd voor de managementrapportages. Het precieze aantal unieke PGO-gebruikers per Zorgaanbieder in Nederland kan met deze aangeleverde indicator door DVP's en DVA's niet berekend worden. Aangegeven is door management en adviseurs (zie vooronderzoek) dat trendinformatie voldoende is om inzicht te hebben in verslechtering of verbetering en te kunnen sturen. Het exacte aantal PGO-gebruikers in Nederland is niet nodig. | |
2. | Gegevens die deelnemers delen met MedMij en VZVZ voor het signaleren, melden, analyseren en oplossen van verstoringen en voor managementrapportages is proportioneel met de informatiebehoefte | Er wordt duidelijk beschreven welke gegevens nodig zijn voor welk doeleinde en welke informatiebehoefte. Er worden niet meer loggegevens gedeeld van deelnemers dan nodig is voor de informatiebehoefte | |
3. | Er wordt voldaan aan vigerende wetgeving zoals de AVG | · Er mogen geen persoonsgegevens gedeeld worden of medisch inhoudelijke gegevens alleen transactie gegevens. · Geen gebruik van BSN’s of andere privacygevoelige informatie Opmerking: Wanneer de scope toch mocht veranderen, en het wel persoonsgegevens gewenst wordt om persoonsgegevens te delen, verandert de doorlooptijd van het project aanzienlijk. Omdat er dan aanvullende contracten nodig zijn tussen de betrokkenen voor afspraken over het gebruik van de persoonsgegevens. Een rechtmatige grondslag voor de verwerking is vereist. | |
4. | Er wordt zorgvuldig omgegaan met concurrentie-gevoelige informatie | Deelnemers hebben geen inzage in de activiteiten van andere deelnemers tenzij dit noodzakelijk is voor het oplossen van verstoringen. | |
5. | Er wordt zorgvuldig omgegaan met loggevens die misbruikt kunnen worden door hackers. Vanuit het oogpunt van informatieveiligheid. | ||
Aanvullingen? |