ZTC 1.3 'geforceerd bijwerken' scope onduidelijk

[johannesbattjes]

Scope geforceerd bijwerken moet worden toegepast bij een correctie. Maar autorisaties in de huidige ZGW-standaard zijn niet meer geschikt voor individuele use cases als correctie. Daarvoor zou het nodig zijn om bijvoorbeeld de scope in het jwt-token mee te sturen. Maar er is besloten in de standaard
In een eerdere sprint werden de scope/zaaktypes claims opgenomen in het JWT wat verstuurd wordt van de (taak)applicatie naar de API. Dit is niet langer zo - nu gebruiken we het JWT enkel nog om de (taak)applicatie te autoriseren met de betreffende API te communiceren. De autorisatie van de acties van de applicatie zelf is gedelegeerd naar de Autorisaties API.

Het is dus niet mogelijk, volgens de standaard, om bij een specifieke use case als correctie de scope geforceerd bijwerken mee te sturen. Wat wel kan: de zaaktypebeheertool, waarmee de correctie gedaan wordt, de scope geforceerd bijwerken geven in de AC. Maar dan heeft deze applicatie altijd de scope geforceerd bijwerken, en is de scope dus zinloos geworden.

Voorstel:

• binnen het huidige autorisatiemodel, dus in v1 van de standaard, de scope geforceerd bijwerken laten vervallen. De business rules over correctie leggen voldoende uit wat wanneer wel en niet mag - het is aan de applicatielogica van de ZTC-beheertool dit goed te implementeren;
• in een nieuwe major versie van de standaard een fijnmaziger autorisatiemodel maken. Bijvoorbeeld door de scopes wel weer mee te geven met het token - of op een andere gangbare wijze. Mogelijk ook op gebruikersniveau.

[HenriKorver]

Het is dus niet mogelijk, volgens de standaard, om bij een specifieke use case als correctie de scope geforceerd bijwerken mee te sturen.

Deze redenering klopt niet. Het is namelijk wel mogelijk om de scope geforceerd bijwerken mee te geven. Alleen dat gaat nu indirect via de Autorisaties API. In het JWT-token zit nu alleen de clientID en op basis van deze id kan de aangeroepen API, bijv. de Catalogi AP, zelf de rechten (scopes), zoals bijvoorbeeld wel of niet geforceerd bijwerken, ophalen via de Autorisaties API.

[johannesbattjes]

@HenriKorver wat je zegt is bekend.
Probleem is: in de autorisatiecomponent worden de scopes op applicatieniveau toegekend.
En mijn stelling is dat de correctie altijd via de zaaktypebeheertool wordt toegepast.
Dat betekent dat de zaaktypebeheertool altijd de de scope geforceerd bijwerken zal moeten hebben (naast catalogi schrijven). Daarmee wordt het onderscheid tussen geforceerd bijwerken en catalogi schrijven zinloos.
De scope geforceerd bijwerken zou alleen zin hebben (binnen het huidige model van autorisatie per applicatie) als er een aparte applicatie zou zijn voor correcties.

[HenriKorver]

@johannesbattjes Bedankt voor de uitleg, ik begrijp je punt nu beter. Ik ben het met je eens dat het onderscheid tussen catalogi.geforceerd-schrijven en catalogi.schrijven (zie Scopes voor Catalogi API) waarschijnlijk overbodig is. We zouden dit wellicht in een volgende versie kunnen verfraaien, maar ik zie niet echt een urgent probleem. Hoe erg is het dat je nu voor het zaaktypebeheertool twee extra scopes (catalogi.geforceerd-schrijven en catalogi.geforceerd-verwijderen) moet meegeven om zaaktypes geforceerd te kunnen bijwerken?

[johannesbattjes]

Voor de applicatie 'zaaktypebeheertool' maakt het niet uit. Die geeft namelijk geen scope mee. Zijn scopes worden opgezocht door de ZTC op basis van ClientID in de AC. En deze applicatie zal altijd beide scopes hebben ongeacht of het een correctie of iets anders betreft.

Voor de ZTC maakt het wel uit. Hier moeten we extra logica inbouwen en testen (met en zonder geforceerd bijwerken), die dus zinloos is omdat de ZTCbeheertool altijd beide scopes zal hebben..

Problematischer vind ik dat deze scope een foute verwachting wekt, namelijk dat deze al dan niet "meegegeven" kan worden bij een bepaalde use case (in dit geval correctie) wat niet zo is.