VERSIE: 17-01-2025 STATUS: definitief

1. Inleiding

Het nID netwerkstelsel is de basisinfrastructuur voor veilige gegevensuitwisseling binnen het iWlz-netwerkmodel. Het ondersteunt processen zoals authenticatie, autorisatie, en gegevensraadpleging door gebruik te maken van een federatief model. De kern van het stelsel wordt beheerd door VECOZO en maakt gebruik van open-source componenten, waaronder Open Policy Agent (OPA).

Het nID netwerkstelsel is opgebouwd uit de onderstaande onderdelen en netwerkservices.

• Deelnemers

• Autoriseren

• Datatoegangspunten (Resource-server)

• Policies:

  • Policy Enforcement Point (PEP)

  • Policy Decision Point (PDP)

  • Policy Retrieval Point (PRP)

  • Policy Administration Point (PAP)

  • Policy Information Point (PIP)

De bovenstaande onderdelen en netwerkservices van het nID netwerkstelsel worden in onderstaande paragrafen toegelicht. Hieronder volgt eerst een totaaloverzicht om de relaties tussen de verschillende onderdelen weer te geven.

Open

2. Deelnemers

Om als deelnemer deel te nemen aan het nID netwerkstelsel, is het belangrijk te begrijpen dat toegang en gegevensuitwisseling binnen het stelsel streng worden gereguleerd. Dit waarborgt de beveiliging en naleving van beleidsregels, terwijl het tegelijkertijd een flexibele en efficiënte samenwerking tussen verschillende partijen mogelijk maakt.

Elke deelnemer speelt een rol binnen het federatieve stelsel en moet aan specifieke vereisten voldoen om toegang te krijgen tot registers en andere middelen. Deze vereisten zijn ontworpen om:

• Authenticatie: Zorgen dat alleen vertrouwde partijen deelnemen.

• Autorisatie: Beheersen wie toegang heeft tot welke gegevens.

• Traceerbaarheid: Inzicht bieden in het gebruik van gegevens en acties binnen het stelsel.

Het naleven van deze vereisten is essentieel om een veilige, betrouwbare en compliant werking van het netwerk te garanderen.

2.1. Uitgangspunten om deel te kunnen nemen aan het nID netwerkstelsel

Hieronder zijn de uitgangspunten om deel te kunnen nemen aan het nID netwerkstelsel verwoord.

• Elke deelnemer in het iWlz-netwerkmodel heeft een attest van deelname nodig. Momenteel wordt dit via VECOZO verzorgd tijdens de onboarding.

• Elke deelnemer heeft een authenticatiemiddel van een vertrouwde uitgever. Waar momenteel een VECOZO systeemcertificaat wordt gebruikt, kan t.z.t. ook PKIOverheid worden vertrouwd of het gebruik van DiD en Verifiable Credentials mogelijk zijn.

• Elke deelnemer moet zijn endpoints registreren in het Adresboek, dit geldt voor de endpoints van de autorisatieserver, PEP en de resourceserver. Op dit moment is het Adresboek nog niet gerealiseerd, endpoints worden nu in een aparte lijst bijgehouden. Link tijdelijk Adresboek.

3. Autoriseren

Voor het uitvoeren van alle activiteiten in het iWlz-netwerkmodel zijn autorisaties noodzakelijk. Voorbeelden van activiteiten zijn: lezen, schrijven, aanpassen en verwijderen van data uit registers. Daarnaast zijn er ook autorisaties nodig voor het mogen versturen van notificaties en meldingen. Deze autorisaties kunnen worden aangevraagd bij de autorisatieserver. Voor het aanvragen van een autorisatie heeft een deelnemer een authenticatiemiddel nodig van een vertrouwde uitgever.

3.1. Schematische weergave aanvragen van autorisatie

In het onderstaande schema wordt de basis uitgelegd voor het aanvragen van autorisatie en hoe vervolgens een raadpleging (GraphQL request) verloopt.

Open

3.2. Autorisatieserver

Binnen het netwerk is momenteel een autorisatieserver beschikbaar, bij deze autorisatieserver kunnen netwerkdeelnemers toestemming tot autorisatie aanvragen. De autorisatieaanvraag voldoet aan de OAuth 2.0 standaard. Het resultaat van de aanvraag is een access-token (JWT).

Toegang tot deze autorisatieserver is beperkt tot alleen netwerkdeelnemers en alleen via het token-endpoint waarvoor een vertrouwd authenticatiemiddel vereist is. Momenteel alleen met gebruik van een VECOZO systeemcertificaat.

Op dit moment worden de endpoints in een aparte lijst bijgehouden. Link tijdelijk Adresboek.

3.2.1. Grant_type

OAuth 2.0 ondersteunt verschillende "flow standaarden" (ook wel grants genoemd) om toegang te verlenen. Voor server-naar-server communicatie wordt meestal de “Client Credential Flow” toegepast. Deze “Client Credential flow” wordt ook gebruikt bij het aanvragen van toestemming tot autorisatie bij de autorisatieserver in het netwerk stelsel.

Voor meer informatie zie Logius NL GOV Assurance profile for OAuth 2.0 v1.1.0.

3.2.2. Scopes

Een (OAuth) scope geeft het bereik van autorisatie tot een resource aan. Een scope kan een deelnemer bij de autorisatieserver aanvragen. Dit zal het systeem gebruiken om na te gaan welke acties een gebruiker mag doen voor het raadplegen van registers. De autorisatieserver vereist dat de client in het autorisatieverzoek een scope parameter specificeert. 

De scope speelt een cruciale rol in het aanvragen van autorisatie. De scope geeft het bereik aan waarvoor autorisatie wordt aangevraagd en daarmee beperkt en specificeert welke gegevens of functionaliteiten de client kan gebruiken of bevragen. 

Een scope is opgebouwd uit de combinatie van resource_type en de benodigde toegang.

Voorbeeld: De onderstaande scope is bruikbaar voor de autorisatieaanvraag tot het opvragen (read) van indicatiegegevens uit het indicatieregister:

Indien de autorisatieserver de scope van de aanvraag goedkeurt, zal de “scope” in het access-token terugkomen. De waarde van de scope parameter in het verzoek is uitgedrukt als een spatie-gescheiden lijst van case-sensitive strings.

De volgorde van de spatie-gescheiden strings is onbelangrijk. De autorisatieserver zal elke string verwerken als extra scope in het access-token. Indien er 2 dezelfde scopes worden meegegeven, dan worden deze samengevoegd tot 1 unieke scope. 

Voor een goede request flow is het nodig om de scope in de request body op te stellen zoals in onderstaande voorbeelden wordt weergegeven.

Voorbeeld: van een scope request parameter waarin meerdere scopes worden aangevraagd:

Als een client een scope aanvraagt waarvoor hij geen autorisatie heeft, dan zal de autorisatieserver een foutmelding retourneren "Access denied, invalid scope", ongeacht of er in dezelfde aanvraag scopes zitten waarvoor wel is geautoriseerd. 

Als de client geen of een lege scope parameter meegeeft in zijn request aan de autorisatieserver, dan MOET de autorisatieserver het verzoek verwerken door een vooraf gedefinieerde standaard scope toe te passen of een "Invalid scope" foutmelding te retourneren. Als de autorisatieserver een verzoek ontvangt waar 1 of meerdere Scopes incorrect zijn MOET de autorisatieserver een "Access denied, invalid scope" retourneren.

Een standaard scope zou kunnen zijn: “user/profile:read” (Deze scope is als voorbeeld en bestaat in het huidige netwerkmodel niet)

De scopes zijn beschreven in de verschillende diensten of uitwisselprofielen.

3.2.3. Audience

Als je in OAuth een Access-token aanvraagt, moet je specificeren wie of wat de uiteindelijke ontvanger van deze token is, deze ontvanger wordt aangeduid als Audience. Dit helpt om te verzekeren dat het token alleen kan worden gebruikt bij de bedoelde resource-server en nergens anders.

• Het opgeven van een Audience is verplicht. 

• Enkel is één Audience toegestaan.

• De audience moet een valide “https” URL zijn. De Audience is de afgeschermde URL van de resource-server welke ook alleen de Policy Enforcement Point van de resource-server vertrouwd.

3.2.4. Access-token request

Een Access-token request is een toegangsverzoek om toegang te krijgen tot een datatoegangspunt zoals een register. In een Access-token request wordt aangegeven namens wie het request wordt uitgevoerd. Dit kan op twee manieren, als de partij zelf of als actor namens een partij. In beide gevallen wordt een request gedaan met een VECOZO systeemcertificaat (VECOZO authenticatiemiddel) om te bepalen wie de partij is.

Softwareleveranciers of intermediairs, die namens zorgaanbieders of zorgkantoren handelen, maken hierbij gebruik van een actor om aanvragen in te dienen.

Om toegang te krijgen tot een datatoegangspunt zoals een register, moet in het tokenaanvraagproces naast het VECOZO-systeemcertificaat ook worden aangegeven namens welke partij de actor handelt. Deze partijen kunnen momenteel zorgaanbieders (geïdentificeerd door AGB-codes) of zorgkantoren (geïdentificeerd door UZOVI-codes) zijn.

De actor fungeert als vertegenwoordiger van de instantie en zorgt ervoor dat toegangsverzoeken correct en veilig worden geautoriseerd, zodat altijd duidelijk is namens welke partij de aanvraag wordt uitgevoerd.

Voor zowel een eigen aanvraag als een aanvraag namens een andere partij geldt:

• Een request header MOET het Content-Type: application/json bevatten om aan te geven dat de body in JSON formaat is.

• Een token request kan alleen worden aangevraagd met een VECOZO systeemcertificaat dit wordt dan gezien als een VECOZO identity.

• De maximale access-token-duration (exp) is 1 uur, ongeacht de scope.

Hieronder worden voor zowel een eigen aanvraag als een aanvraag namens een andere partij voorbeelden gegeven van een access-token request.

3.2.4.1 Een Access-token aanvragen voor jezelf

Een partij vraagt een Access-token aan voor zichzelf. Een voorbeeld hiervan is:

De response is een JWT:

3.2.4.2 Een Access-token aanvragen namens een andere partij

Wanneer als actor een request wordt ingediend, moet het token worden uitgebreid met een “access_token/sub” element. Dit element bevat de identificatie van de partij waarvoor een token wordt opgehaald. Op het moment kan er geacteerd worden als zorgkantoor of zorgaanbieder. De waarde van het element kan er als volgt uit zien:

Voorbeeld Access-token request als actor namens een zorgkantoor:

De response is een JWT:

4. Datatoegangspunten (Resource-server)

Datatoegangspunten, ook wel resource-servers genoemd, zijn de eindpunten binnen het nID-netwerkstelsel waar gegevens toegankelijk worden gemaakt. Ze vormen een cruciaal onderdeel in de gegevensverwerking en worden alleen bereikt wanneer een verzoek succesvol is gevalideerd door de voorafgaande beveiligings- en autorisatieprocessen.

4.1. Functies van datatoegangspunten

De datatoegangspunten hebben in het algemeen een aantal functies die hieronder worden toegelicht.

4.1.1. Dataopslag en raadpleging:

1. Gegevensbeheer:

   • Een datatoegangspunt beheert en verstrekt gegevens op basis van goedgekeurde toegangsverzoeken.

   • Alleen de gegevens die voldoen aan de beleidsregels worden ontsloten.

2. Dataconsistentie:

   • Registers moeten data consistent opslaan en up-to-date houden, zelfs bij hoge belasting of parallelle aanvragen.

3. Auditlogboek:

   • Alle dataraadplegingen en wijzigingen moeten worden vastgelegd in een auditlogboek voor compliance en toezicht.

4.1.2. Veiligheid en toegangscontrole

1. Authenticatie en autorisatie: Elk verzoek moet worden gevalideerd op basis van een Access-token, scope en beleidsregels via het Policy Enforcement Point (PEP).

2. Encryptie: Alle opgeslagen data en dataverkeer tussen de PEP en het datatoegangspunt moeten worden versleuteld (bijvoorbeeld TLS 1.2+).

3. Minimale toegangsrechten:

   • Registers moeten werken volgens het least privilege-principe, waarbij deelnemers alleen toegang krijgen tot de gegevens die strikt noodzakelijk zijn.

4. Bescherming tegen misbruik:

   • Er moeten limieten worden ingesteld op het aantal toegangsverzoeken (rate limiting) om misbruik, zoals DDoS-aanvallen, te voorkomen.

4.1.3. Schaalbaarheid en prestaties

1. Schaalbare architectuur:

   • Datatoegangspunten moeten schaalbaar zijn, zowel horizontaal als verticaal, om een toenemend aantal gebruikers en verzoeken te ondersteunen.

2. Caching:

   • Implementatie van caching voor veelvoorkomende dataquery’s om de responstijd te verbeteren en de belasting op de database te verminderen.

3. Laag latency:

   • Verzoeken moeten binnen een acceptabele tijd worden verwerkt, zelfs bij piekbelasting.

4.1.4. Interactie met de PEP

1. Routing van verzoeken:

   1. Het Policy Enforcement Point (PEP) moet verzoeken naar het juiste datatoegangspunt routeren, afhankelijk van de gevraagde gegevens en beleidsregels. Het adresboek zal gebruikt worden voor het registreren van de endpoints en contactgegevens van de verschillende registers.

2. Feedbackloop naar de PEP:

   1. Het datatoegangspunt moet duidelijke foutcodes en antwoorden verstrekken aan de PEP om de client correct te informeren (bijvoorbeeld 403 Toegang Geweigerd).

4.1.5. Overige vereisten

1. Ondersteuning voor meerdere datatypen:

   • Registers moeten verschillende datatypen ondersteunen met GraphQL als interface om flexibiliteit en standaardisatie in de raadpleging te bieden.

2. Logische scheiding van data:

   • Gegevens van verschillende gebruikers of organisaties moeten strikt gescheiden worden opgeslagen.

3. Monitoring en rapportage:

   • Monitoring van gebruik, prestaties en fouten is essentieel voor proactief beheer en optimalisatie.

4.2. Procesflow interactie met een datatoegangspunt

Hier is een diagram dat de interactie met een datatoegangspunt schematisch weergeeft:

5. Policy Enforcement Point (PEP)

Een Policy Enforcement Point (PEP) regelt toegang tot resource-servers van deelnemers en beschermt deze resource-servers tegen ongeautoriseerde toegang/verzoeken. 

De PEP stuurt alle toegangsverzoeken naar resource-servers eerst door naar het PDP ter beoordeling. Waarna (conform de beslissing) het verzoek wordt toegestaan of wordt afgewezen (Allow of Deny).

• De PEP is voor netwerkdeelnemers alleen toegankelijk op het GraphQL-endpoint.

• De PEP vereist een vertrouwd authenticatiemiddel en een geldig Access-Token.

• De netwerkdeelnemer registreert zelf in het adresboek welke PEP zijn resource-server beschermt.

• De resource-servers van de netwerkdeelnemers vertrouwen de PEP op het valideren van de grondslag.

• In het netwerk is momenteel maar één PEP(redundant) beschikbaar. In de toekomst zijn meerdere zelfstandige PEPs voorstelbaar.

5.1 GraphQL Request naar de PEP

Het versturen van een GraphQL Request naar de PEP is onderdeel binnen het toegangscontroleproces van het nID-netwerkstelsel. Dit proces stelt een deelnemer (client) in staat om met behulp van een access-token een verzoek te doen bij de Policy Enforcement Point (PEP). De PEP speelt hierbij een centrale rol door de query te valideren, beleidsregels toe te passen en uiteindelijk het verzoek door te sturen naar de juiste resource-server voor verdere verwerking.

Het huidige endpoint dat wordt aangesproken is de resource-server. Hier wordt een reeks validatiestappen doorlopen om de veiligheid, integriteit en naleving van beleidsregels te waarborgen voordat een verzoek wordt afgehandeld. Deze validatiestappen zijn nodig om ervoor te zorgen dat alleen geautoriseerde verzoeken toegang krijgen tot de gevraagde gegevens.

5.2 Procesflow interactie met de PEP

Hier is een diagram dat de interactie met een PEP schematisch weergeeft:

Na stap 8 van bovenstaande procesflow wordt het request dat is toegestaan doorgestuurd naar de resource server. Aan dit request wordt een request header ‘claims’ toegevoegd met daarin de door de deelnemer gebruikte JWT exclusief de JWT header en signature. Deze header kan gebruikt worden voor eventuele logging doeleinden door de resource server.

Voorbeeld van een request header ‘claims’:

5.3 PEP Endpoints

In het netwerkstelsel zijn momenteel onderstaande PEP’s in gebruik.

Let op: De URL bevat de term resource-server, dit is incorrect en zal t.z.t. worden vervangen door PEP.

6. Policy Decision Point (PDP)

Het Policy Decision Point (PDP) speelt een centrale rol in de toegangscontrole. Het PDP is verantwoordelijk voor het nemen van toegangsbeslissingen op basis van beleidsregels (policies) en analyseert toegangsverzoeken die worden ingediend met een GraphQL-query.

Hieronder een diagram dat de interactie tussen het PDP en andere componenten schetst:

In onderstaande stappen wordt uitgelegd hoe het Policy Decision Point PDP werkt.

7. Policy Retrieval Point (PRP)

Het Policy Retrieval Point (PRP) speelt een cruciale rol in het beheer en de levering van beleidsregels (policies) binnen het nID-netwerkstelsel. Als centrale opslagplaats zorgt het PRP ervoor dat beleidsregels consistent worden opgeslagen, beheerd en toegankelijk zijn voor andere onderdelen, zoals het Policy Decision Point (PDP). Deze centrale aanpak waarborgt dat alle toegangsbeslissingen gebaseerd zijn op dezelfde regels, waardoor consistentie in toegangscontrole wordt gegarandeerd.

Daarnaast biedt het PRP transparantie door gebruik te maken van een versiebeheersysteem, zoals GitHub, waarmee alle wijzigingen in beleidsregels inzichtelijk en traceerbaar zijn. Dit maakt het eenvoudig om beleidsregels te beheren, bij te werken en wijzigingen consistent door te voeren in het hele netwerk, wat de beheerbaarheid aanzienlijk vergroot.

7.1. Functies van het PRP

Het PRP zorgt ervoor dat het Policy Decision Point (PDP) altijd beschikt over de meest actuele beleidsregels, wat cruciaal is voor nauwkeurige en veilige toegangsbeslissingen. Met functies zoals versiebeheer, efficiënte distributie en integratie met het Policy Administration Point (PAP), biedt het PRP een betrouwbare en schaalbare oplossing voor toegangscontrole binnen het netwerk.

1. Opslag van beleidsregels:

   • Het PRP fungeert als repository voor alle beleidsregels die bepalen wie toegang heeft tot welke resources.

   • Beleidsregels worden beheerd door het Policy Administration Point (PAP) en opgeslagen in een centrale locatie.

2. Toegankelijkheid voor het PDP:

   • Wanneer het PDP een toegangsverzoek ontvangt, haalt het de relevante beleidsregels op uit het PRP.

   • Dit zorgt ervoor dat toegangsbeslissingen altijd gebaseerd zijn op de meest actuele beleidsregels.

3. Versiebeheer en wijzigingen:

   • Het PRP biedt mogelijkheden om wijzigingen in beleidsregels bij te houden. Dit zorgt voor consistente en traceerbare toegangscontrole.

4. Efficiënte distributie:

   • Het PRP maakt beleidsregels toegankelijk via gestructureerde processen (zoals API-aanroepen of Git-integraties), zodat het PDP snel en betrouwbaar toegang heeft tot de benodigde informatie.

7.2. PRP in de huidige implementatie

In de huidige implementatie binnen het nID-netwerkstelsel worden beleidsregels opgeslagen in een OCI-repository binnen de VECOZO-organisatie. Dit functioneert als een praktische en schaalbare PRP-oplossing:

1. Cloud opslag en Geografische Ondersteuning:

   • Beleidsregels worden beheerd op een centrale opslag en worden automatisch opgehaald naar een beveiligde punt.

   • De laatste versie van beleidsregels wordt opgehaald en kan worden gerepliceerd over verschillende geografische gebieden.

2. Bevraging door het PDP:

   • Het PDP kan beleidsregels dynamisch ophalen uit de repository wanneer een toegangsbeslissing moet worden genomen.

3. Beheer en bijwerken:

   • Het bijwerken van policies gebeurd door een geautomatiseerde uitrol met goedkeuring. Na uitrol zal de nieuwe versie opgeslagen worden op de centrale plek, waarna het systeem deze dan automatisch ophaalt en gebruikt voor de validatie.

8. Policy Administration Point (PAP)

Het Policy Administration Point (PAP) is verantwoordelijk voor het beheren en onderhouden van beleidsregels (policies) binnen het nID-netwerk. Het PAP biedt een interface voor het creëren, aanpassen, en verwijderen van beleidsregels, en zorgt ervoor dat deze regels consistent beschikbaar zijn voor andere componenten zoals het Policy Retrieval Point (PRP) en het Policy Decision Point (PDP). Een GitHub repository in de VECOZO-organisatie dient momenteel als PAP voor de policies van nID-netwerkstelsel.

Het proces van het PAP bestaat uit een reeks stappen die zorgen voor een gestructureerd beheer en veilige implementatie van beleidsregels. Hieronder wordt de procesflow beschreven.

9. Policy Information Point (PIP)

Het Policy Information Point (PIP) is een integraal onderdeel van het nID-netwerkstelsel en speelt een cruciale rol in het ondersteunen van toegangsbeslissingen. Het PIP levert contextuele informatie die nodig is voor het evalueren van toegangsverzoeken. Deze informatie kan afkomstig zijn uit externe bronnen of interne gegevensbronnen binnen het netwerk en versterkt de toegangscontrole op meerdere manieren.

Door het gebruik van contextinformatie biedt het PIP flexibiliteit, waardoor beleidsregels kunnen worden afgestemd op complexe scenario’s. Daarnaast maakt het PIP real-time besluitvorming mogelijk, omdat het actuele gegevens levert die essentieel zijn voor nauwkeurige en tijdige toegangsbeslissingen. Bovendien zorgt de mogelijkheid om meerdere bronnen te koppelen voor schaalbaarheid, wat uitgebreide en efficiënte beleidsregels binnen het nID-netwerk mogelijk maakt.

Het PIP heeft een aantal functies voor het leveren van contextinformatie. Deze worden hieronder toegelicht.

Leveren van contextinformatie

Het PIP verstrekt aanvullende gegevens die nodig zijn om een toegangsbesluit te nemen.

Voorbeelden:

• Identiteit of rol van de deelnemer.

• Tijdgebonden restricties.

• Relaties tussen entiteiten (bijvoorbeeld een zorgverlener en een patiënt).

Interactie met de PDP

Het PIP wordt geraadpleegd door het Policy Decision Point (PDP) wanneer meer informatie nodig is om een beleidsregel toe te passen.

De opgevraagde informatie wordt dynamisch opgehaald en teruggekoppeld aan de PDP.

Ondersteuning van beleidsregels

Door aanvullende gegevens beschikbaar te stellen, maakt het PIP flexibele en gedetailleerde beleidsregels mogelijk.

Beleidsregels kunnen afhankelijk zijn van complexe contextuele relaties die door het PIP worden verstrekt.

Verbinding met externe bronnen

Het PIP kan worden gekoppeld aan externe systemen, zoals registers of databases, om real-time informatie op te halen.

Met deze combinatie van flexibiliteit, real-time capaciteiten en schaalbaarheid vormt het PIP een onmisbare schakel in het toegangscontroleproces.

10. Foutmeldingen

OAuth HTTP Error Responses

In het onderstaande schema staan de mogelijke foutmeldingen die kunnen optreden bij het ophalen van autorisaties of het uitvoeren van een GraphQL-verzoek.

Overzicht van HTTP Error Responses

Let op: foutmeldingen kunnen afhankelijk van de geïmplementeerde client anders worden weergegeven.

NB 1: GraphQL 200 OK

Een GraphQL 200 OK response kan inhoudelijk nog steeds een fout-melding bevatten. De standaard beschrijft dat wanneer een GraphQL request door de server is ontvangen er altijd een 200 OK response volgt. Dit betekent niet automatisch dat de query volledig succesvol kon worden afgehandeld.

NB 2: Inhoud Error Responses

Het overzicht geeft de mogelijke HTTP Error responses vanuit voornamelijk de PEP. Dezelfde fouten kunnen ook voorkomen bij de Resource-server. Een onderscheid in afzender moet mogelijk zijn. In een volgende update zal er afzenderinformatie in de message-body moeten worden toegevoegd.

10.1 Foutmeldingen Aanvraag van Autorisatie

[01] 400 Audience Required

• HTTP Response:

• Details:
  Controleer of alle headers op de juiste manier worden meegegeven zoals: ‘content-type’. Het netwerkmodel gebruikt de flow standaard (grant_type) “client_credentials”. Een audience en scopeparameter zijn vereist bij het aanvragen van een token. Voeg deze toe aan de request body.

  Bijvoorbeeld:

[02] 401 Unauthorized

• HTTP Response:

• Details:
  Er kan niet geacteerd worden namens een partij (subject), omdat hier geen rechten voor zijn geregistreerd. Indien subject en actor hetzelfde zijn, dan wordt deze foutmelding ook gegeven.

  • Controleer of acteren mogelijk moet zijn en neem contact op met VECOZO.

  • Verander de body zodat er als directe partij een aanvraag wordt gedaan.

  Voorbeeld body als er geacteerd wordt namens een partij:

  Voorbeeld body als aanvraag wordt gedaan als directe partij:

[03] 403 Not Allowed

• HTTP Response: 

• Details:
  Mogelijke oorzaken zijn:

  • Het IP-adres is niet geregistreerd bij het authenticatiemiddel.

  • Het authenticatiemiddel kan geblokkeerd zijn. Neem contact op met de VECOZO contactpersoon binnen uw organisatie, deze kan in de portaal van VECOZO controleren of uw IP-adres is opgenomen in de lijst van IP-adressen.

  • Hoe kan ik mijn IP-adres registreren? - (https://www.vecozo.nl/support/controle-op-ip-adressen/ip-adres-registreren/hoe-kan-ik-mijn-ip-adres-registreren/ )

[04] 403 Invalid Client Certificate

• HTTP Response: 

• Details:
  Het certificaat ontbreekt, is ongeldig of verlopen (van toepassing bij gebruik van een VECOZO-systeemcertificaat). Zorg ervoor dat het authenticatiemiddel overeenkomt met de juiste omgeving.

  Uw certificaat installeren of vernieuwen - (https://www.vecozo.nl/certificaten-installerenvernieuwen/ ) of neem contact op met VECOZO Functioneel Beheer.

[05] 404 Not Found

• HTTP Response: 

• Details:
  Een onjuist endpoint van de autorisatieserver is gebruikt. Controleer of het correcte endpoint is geconfigureerd, zoals gespecificeerd in dit document onder de details van de autorisatieserver.

[06] 500 Internal Server Error

• HTTP Response: 

• Details:
  Een onverwachte fout is opgetreden op de autorisatieserver. Probeer het later opnieuw of volg het incidentbeheerproces indien nodig.

10.2 Foutmeldingen PEP endpoint bij GraphQL request

[01] 400 Invalid Query Syntax

• HTTP Response: 

• Details:
  De query voldoet niet aan de vereiste syntax. Controleer de structuur van de query aan de hand van de specificaties.

[02] 400 No Operation

• HTTP Response: 

• Details:
  Er ontbreekt een geldige operatie in de GraphQL-aanvraag. Controleer en pas de query aan om een bewerking te definiëren.

[03] 400 Invalid Scope

• HTTP Response: 

• Details:
  De opgevraagde scope komt niet overeen met de toegestane scope. Controleer de scope-instellingen.

[04] 401 Unauthorized

• HTTP Response:

• Details:
  De toegang werd geweigerd, omdat er mogelijk een access token ontbrak. Controleer of het access token correct is aangevraagd en wordt meegegeven. Indien de fout zich blijft voordoen, kunt u het incidentbeheerproces volgen.

[05] 401 Not Allowed

• HTTP Response: 

• Details:
  Mogelijke oorzaken zijn:

  • Het IP-adres is niet geregistreerd bij het authenticatiemiddel.

  • Het authenticatiemiddel kan geblokkeerd zijn. Neem contact op met de VECOZO contactpersoon binnen uw organisatie, deze kan in de portaal van VECOZO controleren of uw IP-adres is opgenomen in de lijst van IP-adressen.

  • Voor meer informatie ga naar: Hoe kan ik mijn IP-adres registreren? - https://www.vecozo.nl/support/controle-op-ip-adressen/ip-adres-registreren/hoe-kan-ik-mijn-ip-adres-registreren/

[06] 403 Invalid Client Certificate

• HTTP Response: 

• Details:
  Het certificaat ontbreekt, is ongeldig of verlopen (van toepassing bij gebruik van een VECOZO-systeemcertificaat). Zorg ervoor dat het authenticatiemiddel overeenkomt met de juiste omgeving.

  Voor meer informatie ga naar: Uw certificaat installeren of vernieuwen - https://www.vecozo.nl/certificaten-installerenvernieuwen/ of neem contact op met VECOZO Functioneel Beheer

[07] 403 Policy: Access Denied

• HTTP Response:

• Details:
  Toegang geweigerd op basis van een policy. De toegangsrechten van het gebruikte authenticatiemiddel voldoen niet aan de toegangsvereisten. Controleer de query en probeer opnieuw.

[08] 403 Request Does Not Match Scopes

• HTTP Response:

• Details:
  De aanvraag voldoet niet aan de vereiste scopes in het access token. Controleer de toegewezen scopes. Vraag een nieuwe access token aan indien de token voor een andere scope bestemd is.

[09] 500 Internal Server Error

• HTTP Response: 

• Details:
  Er is een onverwachte fout opgetreden op de server. Probeer het later opnieuw of raadpleeg het incidentbeheerproces.

[10] 502 Bad Gateway

• HTTP Response: 

• Details:
  De server kreeg een ongeldige reactie van een upstream-server. Controleer de serverinstellingen of probeer het later opnieuw.

[11] 504 Gateway Timeout

• HTTP Response: 

• Details:
  De server reageerde niet binnen de verwachte tijd. Controleer de serververbindingen of probeer het later opnieuw.