Als beheerder wil ik applicatie autorisaties kunnen inregelen

[matthiasoliveiro]

zodat er onderscheid gemaakt kan worden wie wat mag en welke gegevens mag zien

[matthiasoliveiro]

Deze moet gesplitst worden in een losse story Authorizatie en Authenticatie het zijn namelijk losse dingen.

[matthiasoliveiro]

Gesplitst om meer overzicht te creëren.

[rubenvdlinde]

Defacto kunnen we voor autorisatie het autorisatie component van zgw gebruiken. Het zou wenselijk zijn als daar dan wat dingen op worden toegevoegd en aangepast. Maar binnen de gedachte van samenwerken willen ze dat vast wel doen als we er goede issues voor inschieten. En anders hebben we @CMasselink nog ;)

Authenticatie (het vaststellen van de gebruiker) is echter weer iets anders, als ik de zgw componenten zo lees hebben ze het daar ingebakken. Ik weet niet of ik daar van van ben, als je notificaties en autorisatie loskoppelt van een component is het wellicht logisch om die lijn door te trekken en authenticatie ook in een los component onder te brengen. @ThijsBroersen wat vind jij?

[CMasselink]

@rubenvdlinde op welk niveau bedoel je authenticatie? Tussen applicaties/api's of op user niveau? Op user niveau doet het autorisatie component niks voor authenticatie. Authenticatie van een gebruiker los je typisch op in de taakapplicatie. Vaak met iets als ADFS als het om medewerkers gaat en DigiD voor burgers. Authenticatie wordt dan afgehandeld door de authenticatie service / identity provider van de gemeente (in geval van een medewerker).

Let op: In het autorisatie component worden autorisaties tussen consumers (een api die een andere api nodig heeft kan ook als consumer acteren) en providers geregeld. Wat een gebruiker mag binnen een applicatie, zit er niet in en moet binnen de applicatie geregeld worden.

[rubenvdlinde]

Eens, dat zijn losse dingen. Voor trouwplanner spelen ze overigens beide maar wel los.

Als ik naar het autorisatie component van zgw kijk dan zie ik echter niks staan over authenticatie tussen applicaties, zowel in de calls als in de overwegingen er staan calls in per applicatie vast te stellen wat de rechten zijn. Maar ik kan geen calls of overwegingen terugvinden over hoe er wordt vastgesteld dat een call van een applicatie afkomstig is.

Voor zover ik dat kan re-engineren aan de hand van de overige zgw api's wordt er een JWT token validatie toegepast, en er bestaat zo iets al een token tool. Maar wat ik niet terug kan vinden in de algemene informatie, themas, authorisatie documentatie, ontwikkelaars documentatie en api standaarden is hoe JWT tokens worden gegenereerd en wie er voor verantwoordelijk is, ofwel hoe komt een applicatie aan een jwt token en controleer ik de validiteit daarvan. Zijn de providers daarvoor vernantwoordelijk? (de zgw token tool) sugereerd van wel. En hoe ver gaat die verantwoordelijkheid? vertrouw ik tokens van andere applicaties gergeld etc.

Ofwel Autorisatie komen we wel uit aan de hand van de docs en componenten, Authenticatie (tussen applicaties) vraagt nog wat aanvullende documentatie (die we lijken te missen, hij zal er vast zijn).

[CMasselink]

@rubenvdlinde : zie https://gist.github.com/sergei-maertens/1f8e43e4bf8bed718894974426d14ec6 voor de uitleg over het JWT token. Klopt dus dat je in de documentatie het niet terug kan vinden. Het is er wel maar bij onze laatste herstructurering van de documentatie is dat weggevallen (en gaan we dus herstellen).

[rubenvdlinde]

@CMasselink Ah top! Thanxs. Ik ga het lezen, zal ik de vragen die ik heb over authenticatie anders in de ZGW repro stellen? ZGW is hier immers in the lead en heeft de antwoorden.

Dan link ik de issues vanaf hier aan zodat we ook hier wat overzicht houden.

[CMasselink]

@rubenvdlinde Als het gewoon om vragen gaat hoe iets werkt, kan je dat denk ik beter via de community slack doen.