Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZTC 1.3 'geforceerd bijwerken' scope onduidelijk #2477

Open
johannesbattjes opened this issue Sep 19, 2024 · 5 comments
Open

ZTC 1.3 'geforceerd bijwerken' scope onduidelijk #2477

johannesbattjes opened this issue Sep 19, 2024 · 5 comments
Labels
2024 bug Iets werkt niet zoals bedoeld catalogi-api Prio M Prioriteit Medium voorstel

Comments

@johannesbattjes
Copy link

johannesbattjes commented Sep 19, 2024

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
Copy link
Collaborator

HenriKorver commented Sep 19, 2024

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
Copy link
Author

@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
Copy link
Collaborator

HenriKorver commented Sep 20, 2024

@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
Copy link
Author

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.

@HenriKorver
Copy link
Collaborator

@johannesbattjes: Bedankt voor je heldere antwoord.

@joeribekker, @sergei-maertens: Hebben jullie bezwaar als we de scope catalogi.geforceerd-schrijven laten vervallen conform bovenstaand voorstel van Johannes?

PS Deze wijziging is niet backwards compatible, dus we zullen waarschijnlijk eerst de scope catalogi.geforceerd-schrijven deprecated moeten maken alvorens we deze scope in een latere versie echt kunnen verwijderen.

@HenriKorver HenriKorver added bug Iets werkt niet zoals bedoeld voorstel catalogi-api Prio M Prioriteit Medium and removed Vraag Vraag labels Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2024 bug Iets werkt niet zoals bedoeld catalogi-api Prio M Prioriteit Medium voorstel
Projects
Development

No branches or pull requests

2 participants