search

VNG-Realisatie / gemma-zaken

Samen ontwikkelen van API's voor Zaakgericht werken
https://vng-realisatie.github.io/gemma-zaken/
Other
41 stars 27 forks source link

Als gemeente wil ik het autorisatiecomponent ook voor andere componenten / generiek kunnen gebruiken #1548

Open CMasselink opened 4 years ago

CMasselink commented 4 years ago

zodat we componenten echt herbruikbaar kunnen maken / gebruiken. Voorbeeld: voor de huwelijksplanner hebben we ook een autorisatiecomponent nodig. We willen dit niet opnieuw hoeven op te zetten maar willen graag gebruik maken van iets wat al ontwikkeld is.

michielverhoef commented 4 years ago

Dat klinkt goed, autorisatie is natuurlijk iets wat breder is dan alleen zaakgericht werken. Alleen moeten we voorkomen dat vanuit verschillende projecten een eigen autorisatieoplossing gemaakt wordt. Misschien is het een idee om de Autorisaties API net als Notificaties in een apart project door te ontwikkelen?

Anders krijgt het ZGW team de verantwoording om wijzigingsverzoeken vanuit andere projecten te beoordelen en door te voeren. Dat kan op zich maar die verzoeken hoeven helemaal niet in de scope van zaakgerichtwerken te liggen en dan zou je de scope van het ZGW team wel heel erg oprekken.

CMasselink commented 4 years ago

Dat klinkt goed, autorisatie is natuurlijk iets wat breder is dan alleen zaakgericht werken. Alleen moeten we voorkomen dat vanuit verschillende projecten een eigen autorisatieoplossing gemaakt wordt. Misschien is het een idee om de Autorisaties API net als Notificaties in een apart project door te ontwikkelen?

Anders krijgt het ZGW team de verantwoording om wijzigingsverzoeken vanuit andere projecten te beoordelen en door te voeren. Dat kan op zich maar die verzoeken hoeven helemaal niet in de scope van zaakgerichtwerken te liggen en dan zou je de scope van het ZGW team wel heel erg oprekken.

Snap ik, maar is het al wel mogelijk om de zaakgericht specifieke zaken die nu in de API spec en het autorisatie component zitten, configureerbaar / generiek te maken?

michielverhoef commented 4 years ago

Ik zou daar wel voorstander van zijn maar moet dit ook even nagaan bij Hugo en Joeri. Het liefst zou ik dit zo snel mogelijk los trekken van het zaakgericht werken en veel generieker oppakken.

Hugo-ter-Doest commented 4 years ago

Laten we morgen 10-3 bespreken of we een open-autorisaties kunnen maken.

Hugo-ter-Doest commented 4 years ago

We staan achter het idee! Lijkt ons een vraag voor het Core team. @CMasselink zou je de vraag daar kunnen stellen?

rubenvdlinde commented 4 years ago

Hey Heren, het is inmiddels een maand later :) Is hier inmiddels al uitsluitsel over?

rubenvdlinde commented 4 years ago

Oeh ik zie dat die in de realisatie huidige sprint terecht is gekomen, gaan we er nog een discussie over hebben?

joeribekker commented 4 years ago

In #1600 is het kort besproken en in Teams uitgebreider. Hieronder de samenvatting:

De Autorisaties API is bedoeld als generiek inzetbaar component. Bij het design is agile-wise gekozen en gekomen tot een vast lijst (enumeratie) van waarden (lees: componenten die gebruik kunnen maken van de Autorisatie API) met het idee dat deze middels patch-releases snel kon worden uitgebreid.

We kunnen echter niet elk component dat bedacht wordt door gemeenten en leveranciers een plek bieden in deze vast lijst. Als 2 partijen bijvoorbeeld een soortgelijk component maken, hoe gaan we deze dan onderscheiden? Daarnaast is een vaste lijst niet flexibel genoeg, en wachten op patch-releases belemmert de voortgang.

We hebben daarom gekozen voor een combinatie aanpak:

1) De lijst van componenten zal alleen die componenten bevatten die door VNG als API (of schema) standaard zijn erkend. Deze lijst wordt middels patch-releases bijgewerkt.

2) De lijst wordt uitgebreid met de waarde "overige" en er komt een nieuw veld waar, indien gekozen is voor "overige", de naam van het component kan worden opgevoerd.

We gebruiken deze constructie o.a. ook bij de Zaken API voor ZAAK-OBJECTen waardoor de geschetste oplossing in lijn is met de andere API's.

Deze oplossing wordt beschikbaar als minor-release en is dan ook backwards compatible en het doel is deze binnen de huidige sprint te releasen.

@rubenvdlinde @CMasselink Wordt met deze oplossing jullie probleem opgelost?

rubenvdlinde commented 4 years ago

Ik denk dat deze route het probleem voor wordt opgelost, en als jullie hem in de huidige sprint mee pakken wordt ik erg blij want dan kunnen we hem aan onze kant ook snel integreren.

In een bredere context vind ik hem ingewikkelder en zou ik liever zien dat we het niet over componenten hebben maar applicaties die autoriseren (dus eigenlijk alleen optie 2 en dan een slagje abstracter) . Dat komt door 2 dingen

  1. het ontbeert de VNG nog aan ene proces om tot standaarden te komen, dus ik zie niet snel een lijst van standaard componenten ontstaan.

    1. We gaan natuurlijk componenten per leverancier krijgen, en een ecosystemen waarin hetzelfde component vaker draaid. Dat loopt vast als we componenten pinnen op naam (we gaan meerdere ipv een unieke uuid per component. Eigenlijk is de component code alleen relevant om de juiste referentie te vinden en verder niet.

  2. Ik zou heeeeeeeeel graag zien die we deze api in een losse code base en losse container kunnen draaien.

CMasselink commented 4 years ago

@joeribekker Volgens mij lost deze oplossing ons probleem op inderdaad! Lijkt me voor nu dus een prima oplossing :)

HenriKorver commented 3 years ago

@joeribekker @alextreme Naast de oplossing die @joeribekker boven schets zal er mijns inziens nog een noot gekraakt moeten worden om de Autorisaties API generiek in te kunnen zetten. In de huidige opzet kan het secret dat gegenereerd wordt door het Token-tool alleen gedeeld worden met de ZGW-componenten en niet met een willekeurige andere API. Dat gaat nu via een POST operatie op een hidden resource die de ZGW-componenten onderhuids aanbieden aan het Token-tool. Een mogelijke oplossing om van deze hard-coded afhankelijkheid af te komen is om het secret via de Autorisaties API uit te wisselen.

joeribekker commented 3 years ago

Even met Henri over gesparred: Mijn mening hierin is dat we de Autorisaties API niet (ook) de taak moeten geven van authenticatie.

Nu heeft elke API zelf de verantwoordelijkheid om gebruikers te identificeren/authenticeren en dat kan op allerlei manieren: JWT, API-token, NLX, API gateway, etc. Als de identiteit is vastgesteld kan de Autorisatie API gebruikt worden om de rechten van de gebruiker op te halen. Het is aan de gemeente/leverancier om "iets" voor authenticatie in te zetten.

De token tool waar Henri het over heeft is enkel bedoeld om er voor te zorgen dat alle referentie implementaties de juiste authenticatie gegevens krijgen om gebruikers te identificeren. Anders moest dit handmatig in elke API worden toegevoegd aangezien elke API op zichzelf staat.

Achteraf gezien hadden we authenticatie wellicht helemaal geen invulling moeten geven in de referentie implementaties maar dat is bij gebruik van JWTs niet voor de hand liggend. De keus voor JWT is wellicht ook aan evaluatie toe nu scopes zijn verplaatst van het JWT naar de Autorisaties API.