Als provider wil ik dat er features komen voor het toepassen van LO autorisaties, zodat ik deze kan implementeren

hvdijk-p5 commented 2 years ago

Op moment van schrijven zijn voor de BRP Api's geen specificaties aanwezig die gaan over het toepassen van autorisaties zoals beschreven in LO3. Tot zover heb ik op eigen inzicht deze autorisaties geïmplementeerd, om tot de ontdekking te komen dat er meer functionaliteit is dan alleen de filtering van rubrieken waar een afnemer recht op heeft.

Ik denk dat het verstandig is als er een feature komt die de toepassing van autorisaties in wat meer details beschrijft. Mogelijk is het nodig dat de LO3 daarvoor nog eens doorgespit wordt. Als developer kan ik dan bij implementatie beter gegronde keuzes maken.

Omdat ik al een groot deel van de autorisaties heb geïmplementeerd, bij deze alvast de regels die ik heb toegepast. Misschien een goed startpunt voor een feature. En natuurlijk de grote vraag of het correct en compleet is.

Geblokkeerde pl

Er worden geen verstrekkingen gedaan van gegevens van geblokkeerde PL-en. (LO3 $3.1.9)

Toepassing autorisaties

Autorisaties worden toegepast als binnen- of buitengemeentelijk. Dit wordt bepaald op basis van een bij authenticatie meegegeven gemeentecode. Is de gemeente van inschrijving op de pl van een persoon gelijk aan de meegegeven gemeentecode, dan wordt de autorisatie als binnengemeentelijk toegepast op alleen deze persoon.

Voor beide geldt:

Voor selectie van de autorisatie wordt gefilterd op Datum ingang tabelregel (Rubriek 35.99.98) <= (datum vandaag) < Datum beëindiging tabelregel (Rubriek 35.99.99). Er wordt 1 actuele autorisatie verwacht, anders Forbidden response met foutmelding "Meer dan 1 autorisaties gevonden."
Voorwaarde: autorisatie gevonden waarin '35.95.67 Medium ad hoc' de waarde “N” of “A” heeft (LO3 $5.4.3)
- anders: Forbidden response met foutmelding "Niet geautoriseerd voor ad hoc bevragingen."
Voorwaarde: wanneer autorisatie rubriek 35.95.66 de waarde "1" heeft dan mag de afnemer adres vragen stellen (LO3 $5.4.3.2)
- anders: wanneer één van de velden gevuld is: (verblijfplaatsnummeraanduidingIdentificatie, verblijfplaatshuisletter, verblijfplaatshuisnummer, verblijfplaatshuisnummertoevoeging, verblijfplaatsstraat, verblijfplaatspostcode, verblijfplaats__gemeenteVanInschrijving) dan Forbidden response met foutmelding "Niet geautoriseerd voor adresbevragingen."

Voor binnengemeentelijk geldt:

Alle gegevens toegestaan, geen filtering

Voor buitengemeentelijk geldt:

Wanneer indicatie geheimhouding (rubriek 35.95.12) aan staat op de autorisatie, dan worden personen met indicatie geheim op de PL (rubriek 07.70.10) die de waarde 2, 4, 6 of 7 hebben niet verstrekt. Voor bevraging op bsn resulteert dit in een 404, zoek resultaten leveren een lijst waar deze persoon niet op voorkomt. (LO3 $5.4.3.1)
Wanneer 'Bijzondere betrekking kind verstrekken (Rubriek 35.95.14)' de waarde 0 heeft dan worden kinderen waar rubriek '09.89.10 Registratie betrekking' voorkomt met de waarde “L” niet verstrekt. (LO3 $5.2.2)
Filtering op basis van 'Rubrieknummer ad hoc (Rubriek 35.95.60)'

Vragen/aandachtspunten:

Adresbevragingen altijd toestaan wanneer verblijfplaats__gemeenteVanInschrijving gevuld is met gemeentecode (binnengemeentelijke bevraging)?
Indicatie geheim filtering ook toepassen op binnengemeentelijk?
LO3 beschrijft dat voor filtering van geheime personen een mededeling wordt gedaan aan de afnemer dat de burger om geheimhouding heeft verzocht. Moet dit teruggekomen in het resultaat ipv 404/lege lijst? Bijv. alleen veld indicatie geheimhouding teruggeven?
Voorwaarderegels zijn ook onderdeel van de autorisaties in LO3. Implementatie hiervan is behoorlijk complex en wordt voorlopig nog niet gedaan. Maar verdient waarschijnlijk dus wel een plek in een feature over autorisaties.

Kunnen jullie hier wat mee?

CathyDingemanse commented 2 years ago

@hvdijk-p5 zou jij e.e.a. kunnen toelichten a.s. maandag? Dan kunnen samen bepalen hoe we dit gaan aanpakken. Ik heb een vergaderverzoek gestuurd.

fsamwel commented 2 years ago

zie ook #855 moeten levenloos geboren kinderen worden opgenomen in het antwoord

fsamwel commented 2 years ago

Zoeken (door niet-gemeente) en in fields vragen om gegevens waarvoor de gebruiker niet geautoriseerd is --> foutmelding

Zoeken (door gemeente) vindt binnengemeentelijk persoon en in fields vragen om gegevens waarvoor de gebruiker niet buitengemeentelijk geautoriseerd is --> kan niet door beperken zoekresultaat

Zoeken (door gemeente) vindt buitengemeentelijke (en evt. ook binnengemeentelijke) personen en in fields vragen om gegevens waarvoor de gebruiker niet buitengemeentelijk geautoriseerd is --> kan niet meer door beperken zoekresultaat

Raadplegen op bsn binnengemeentelijk persoon en in fields vragen om gegevens waarvoor de gebruiker niet buitengemeentelijk geautoriseerd is --> leveren

Raadplegen op bsn buitengemeentelijk persoon en in fields vragen om gegevens waarvoor de gebruiker niet buitengemeentelijk geautoriseerd is --> foutmelding

Zoeken op parameter wanneer je niet voor het gegeven geautoriseerd bent. Bijvoorbeeld niet geautoriseerd voor geboortedatum en zoeken met geboortedatum --> foutmelding

Bij zoeken beperkte subset van resource als response: alle zoekparameters + leeftijd + indicatieOverleden + hele verblijfplaats + adellijkeTitelPredikaat + indicatieGeheim + opschorting + gezagsverhouding + inOnderzoek Reden voor deze gegevens:

zoekparameters zijn de identificerende gegevens
leeftijd t.b.v. identificatie en dataminimaliseren (t.o.v. tonen geboortedatum)
indicatieOverleden hoort bij parameter inclusiefOverledenPersonen
adellijkeTitelPredikaat nodig om volledige naam samen te stellen
indicatieGeheim + opschorting + gezagsverhouding + inOnderzoek om direct te tonen wanneer er iets aan de hand is met deze persoon waar de gebruiker direct bewust van moet zijn, bijv. wanneer gebruiker alleen zoekresultaat gebruikt en niet verder klikt (bijv. wanneer alleen adres werd gezocht)

Bij zoeken is de response al beperkte set, dus fields is niet required.

Toevoegen veld leeftijdWordtDitJaar voor geval alleen geboortejaar bekend is. leeftijdWordtDezeMaand voor geval geboortedag onbekend is en geboortemaand is deze maand. Hiermee wordt voorkomen dat een gebruiker alsnog autorisatie nodig heeft voor geboortedatum (en deze direct ophaalt) en daarmee dataminimalisatie verloren gaat.

Alleen toestaan van gebruik zoekparameters waarvoor de gebruiker geautoriseerd is voor het bijbehorende gegeven. Bijv. als gebruiker niet geautoriseerd is voor geboortedatum (in de response), mag ook niet worden gezocht op zoekparameter geboortedatum.

fsamwel commented 2 years ago

ik zoek ook uit of er deelnemers aan de pilot zijn die betreffende autorisatie niet hebben, zodat hier conditie voor moet worden ingebouwd:

rubriek 35.95.12 Indicatie geheimhouding heeft waarde "1" (niet geautoriseerd voor gegevens personen met indicatie geheim)
rubriek 35.95.14 Bijzondere betrekking kind verstrekken heeft waarde "1" (geautoriseerd voor verstrekken van levenloos geboren kind)
rubriek 35.95.61 Voorwaarderegel ad hoc (voorwaarden voor ad hoc verstrekking of ad hoc adresvragen)
rubriek 35.95.66 Adresvraagbevoegdheid heeft waarde ongelijk aan "1" (niet geautoriseerd voor adresvragen)
rubriek 35.95.67 Medium ad hoc met waarde ongelijk aan “N” of “A” (niet geautoriseerd voor Ad Hoc vragen)
rubriek 35.95.70, 35.95.71 of 35.95.72 met een waarde
rubriek 35.99.98 Datum ingang tabelregel in de toekomst (ligt niet vóór start van de pilot)
rubriek 35.99.99 Datum beëindiging tabelregel gevuld en zo ja, ligt die datum vóór start van de pilot, in de pilot of (ruim) na beëindigen van de pilot (> 4 jaar in de toekomst)

fsamwel commented 2 years ago

@MelvLee @JohanBoer @CathyDingemanse hoe moet het beperken van de response eruit zien voor de POST? Krijg je dan bij gebruik van de burgerservicenummer parameter een andere response dan bij gebruik van de andere parameters?

JohanBoer commented 2 years ago

@MelvLee @JohanBoer @CathyDingemanse hoe moet het beperken van de response eruit zien voor de POST? Krijg je dan bij gebruik van de burgerservicenummer parameter een andere response dan bij gebruik van de andere parameters?

Als je de Get-functionaliteit wilt "spiegelen" moeten we inderdaad een verschil onderkennen tussen de response bij het opvragen van een ingeschrevenPersoon op basis van "alleen" een Burgerservicenummer en de rersponse bij een combinatie van de andere parameters. Dat versterkt mijn vermoeden dat dit niet zo restfull is. Het kan toch niet zo zijn dat de response van dezelfde persoon er anders uitziet afhankelijk van de gebruikte parameter op hetzelfde endpoint ?

Klinkt fishy.

Zoals ook bij de PR aangegeven de vraag of we de verantwoordelijkheid hiervoor dan niet bij de consumer moeten leggen, danwel een andere resource (en dus endpoint) moeten definieren voor het zoeken van een ingeschrevenPersoonBeperkt.

MelvLee commented 2 years ago

Ik zou ervoor kiezen om twee request body te definieren. Eén voor zoeken en één voor raadplegen. Dit betekent ook dat je twee response krijgt. Of je moet zoals @JohanBoer aangeeft een ander endpoint gebruiken. Maar wat ik veel beter vind is om het raadplegen op basis van een id te laten gebeuren en niet met bsn. Dan is het niet nodig een POST variant voor raadplegen te maken. En help je hiermee de consumer om te voldoen aan de GDPR. Volgens mij moet je om aan de GDPR te voldoen minimaal PII (Personal Identifiable Information) gegevens encrypted opslaan in je database. Als het mogelijk is om een persoon met een uuid op te halen, hoeft een consumer geen bsn's meer in zijn database op te slaan.

fsamwel commented 2 years ago

Maar wat ik veel beter vind is om het raadplegen op basis van een id te laten gebeuren en niet met bsn.

we hebben besloten:

POST variant wordt aparte API (n zelfde repo)
Bij POST variant komt ook GET /ingeschrevenpersonen/{uuid}
Componenten (responses) in domain.yaml
Melvin maakt pull request

hvdijk-p5 commented 2 years ago

Bij deze weer een bombardement met wat vragen/opmerkingen die bij me boven zijn komen drijven. Als jullie weer toelichting nodig hebben dan zie ik jullie vast weer in een meeting. :-)

Fields geautoriseerd, anders foutmelding

wat lost dit precies op?
de bevraging op de database moet dus eerst plaats vinden voordat bepaald kan worden of fields in bevraging geautoriseerd zijn!?
wat als rvig autorisaties verandert, acceptabel dat dan live applicaties mogelijk stuk gaan door foutmelding?
wat als één applicatie voor meerdere afnemers met verschillende autorisaties ingezet wordt? Dezelfde bevraging werkt dan misschien wel voor de ene, niet voor de andere afnemer?
moet er een endpoint komen waar een afnemer zijn geautoriseerde velden op kan halen? Misschien een goed mechanisme als oplossing voor 2 voorgaande vragen?
er moet voor elk veld een mapping komen welke rubriek(en) geautoriseerd moet(en) zijn voor dat veld. Ik denk iets om rekening mee te houden bij maken van een feature.

Beperkte subset zoeken

waarom niet alleen de minimale identificatie, bijv alleen bsn? Met Frank's voorstel is het voor een developer misschien alleen maar lastiger om te bepalen wanneer alleen zoeken voldoende is. Een regel zoals "na zoeken, altijd raadplegen", is dat niet eenvoudiger?

Voorstel leeftijdWordtDitJaar/leeftijdWordtDezeMaand icm autorisatie geboortedatum

Begrijp hier niet wat de bedoeling precies is.

"ik zoek ook uit of er deelnemers aan de pilot zijn die betreffende autorisatie niet hebben, zodat hier conditie voor moet worden ingebouwd"

Niet voorkomen in pilot hopelijk geen reden om belangrijke onderdelen niet op te nemen? Willen we niet naar een specificatie (implementatie) die productie waardig is ongeacht of scenerio's voorkomen in de pilot?

Gebruik POST

Het gebruik van POST voor alleen het ophalen van een resource is niet RESTfull toch? Waarom geen GET met de bsn in de body? Elke ontwikkelaar die met deze api gaat werken heeft ooit geleerd dat POST gelijk staat aan Create. Dit is overigen ook iets wat de DSO strategie voorschrijft. Dus ongeacht het feit dat bsn niet in de url mag zou volgens mij de METHOD nog steeds GET moeten zijn. Of hebben jullie een speciale reden om toch POST te gebruiken?
Verder niet helemaal duidelijk wat Frank bedoeld met wat jullie besloten hebben. Maar dat kan vast makkelijk toegelicht worden.

Nog wat extra zaken die nog ergens op mn lijstje stonden:

Api heeft verschillende maximale resultaten afhankelijk van zoek opdracht, kunnen jullie dat ook ergens specificeren? (vraag ook ooit al bij rvig neergelegd)
Vinden van meer dan 1 persoon met bsn levert 'unique' fout?
In de foutafhandeling feature staan foutcodes die uit de Gba soap service komen. Moeten deze fouten omgezet worden naar een variant die past in een implementatie?

fsamwel commented 2 years ago

Ik heb de autorisaties van de deelnemers gecheckt, m.u.v. "pensioenfondsen" (weet nog niet welke dat zijn). Deze deelnemers hebben de volgende autorisatie-eigenschappen waar wel of niet iets mee moet:

Er zijn autorisaties met einddatum in het verleden (heleboel zelfs), dus daar moet zeker op gecheckt worden
Alle deelnemers hebben 35.95.67 Medium ad hoc gelijk aan N
Er zijn deelnemers met 35.95.66 de waarde "0" (mogen geen adresvragen stellen)
Alle deelnemers hebben 35.95.12 gelijk aan 0
Alle deelnemers hebben 35.95.14 gelijk aan 0 of hebben geen rubriek 35.95.14
Er is één deelnemer met voorwaarderegels op 35.95.61 (ad hoc gegevensverstrekking)
Er zijn geen deelnemers met voorwaarderegels op 35.95.71

fsamwel commented 2 years ago

Adresbevragingen altijd toestaan wanneer verblijfplaats__gemeenteVanInschrijving gevuld is met gemeentecode (binnengemeentelijke bevraging)?

Indicatie geheim filtering ook toepassen op binnengemeentelijk?

RvIG gaat niet over autorisaties voor binnengemeentelijke personen. Dus de API mag nooit een binnengemeentelijke persoon weigeren te leveren aan een gemeente. Elke gemeente heeft 100% autorisatie voor de eigen inwoners.

LO3 beschrijft dat voor filtering van geheime personen een mededeling wordt gedaan aan de afnemer dat de burger om geheimhouding heeft verzocht. Moet dit teruggekomen in het resultaat ipv 404/lege lijst? Bijv. alleen veld indicatie geheimhouding teruggeven?

Als een persoon met geheimhouding niet geleverd wordt bij raadplegen en gebruiker is hier niet voor geautoriseerd, moet dat een foutmelding geven (403). In de details bij de foutmelding kan dan staan dat de burger om geheimhouding heeft verzocht. Maar geen enkele deelnemer heeft 35.95.12=1, dus dit komt voorlopig niet voor.

Voorwaarderegels zijn ook onderdeel van de autorisaties in LO3. Implementatie hiervan is behoorlijk complex en wordt voorlopig nog niet gedaan. Maar verdient waarschijnlijk dus wel een plek in een feature over autorisaties.

Als je wilt weten welke voorwaardenregels 35.95.61 nu gelden, zie: https://publicaties.rvig.nl/dsresource?objectid=0f7e130e-8f51-496c-afdd-4d789aff4a50&type=pdf

Wellicht kan je voor de zekerheid inbouwen dat er een foutmelding (500 of 503?) komt wanneer een (toekomstige) deelnemer een niet-ondersteunde 35.95.61 of 35.95.71 voorwaarderegel heeft.

fsamwel commented 2 years ago

Maar wat ik veel beter vind is om het raadplegen op basis van een id te laten gebeuren en niet met bsn.

we hebben besloten:

POST variant wordt aparte API (n zelfde repo)

Bij POST variant komt ook GET /ingeschrevenpersonen/{uuid}

Componenten (responses) in domain.yaml

Melvin maakt pull request

@MelvLee heb je dit al gedaan? ik zie hier nog geen PR voor. Is het niet handig hier een apart issue van te maken?

fsamwel commented 2 years ago

eerste aanzet voor feature staat klaar in https://github.com/VNG-Realisatie/Haal-Centraal-BRP-bevragen/blob/autorisatie/features/autorisatie.feature

Hierin zijn nog (lang niet) alle vragen van dit issue beantwoord

BRP-API / Haal-Centraal-BRP-bevragen