Contezza Community » Tezza

1. Tezza stuurt een X-API-Resource header mee van de Zaak
   • Contezza-Proxy checkt in Alfresco of de ingelogde gebruiker rechten heeft op de zaak
   • UUID wordt gehasht en daarmee eenvoudig in Alfresco opgezocht
   • Hierdoor hoeft Contezza-Proxy niet UUID's uit de body te halen
2. Tezza stuurt de requests door naar AP-Backend + Alfresco-Event-Listener ==> Dit wordt de nieuwe Tezza-Backend voor ook toekomstige ontwikkelingen
   • AP Backend doet een check of de ingelogde gebruiker volgens de locale AP rechten heeft op de ZaakType
   • AP Backend doet calls naar OpenZaak/Objecten/Notificaties
   • Overige calls blijven via Contezza-Proxy lopen zoals iConnect,BRP waar geen gebruikers-authenticatie nodig is en voor projecten die geen Tezza hebben

Oplossing 1 voegt niets toe qua security.
Bovendien de backend heeft al alle informatie om te valideren als de gebruiker rechten heeft, dus het is ook onlogisch dat de gebruiker iets moet toevoegen.
Contezza-proxy moet de uuid's uit de body halen. Dit is geen overhead, het is gewoon noodzakelijk.

• contezza-proxy moet filters ondersteunen (of config https://git.contezza.nl/develop/alfresco/contezza-proxy/-/blob/main/platform/src/main/resources/alfresco/extension/proxy/tezza-conf.json?ref_type=heads uitbreiden met een optionele veld "filter", of de filter koppelen met de id van de proxy service)
• ContezzaRestProxy https://git.contezza.nl/develop/alfresco/contezza-proxy/-/blob/main/platform/src/main/java/nl/contezza/proxy/webscript/ContezzaRestProxy.java?ref_type=heads moet op basis van configuratie de bijbehorende filter gebruiken om de request te valideren
• deze validatie logica heeft toegang tot de hele request (endpoint, method, body, authenticatiegegevens)
• implementatie van de filter zou in tezza-services moeten horen (dit is mogelijk via spring beans denk ik?), deze implementatie volgt de stappen in de omschrijving van het ticket (en waarschijnlijk iets meer)
• als de filter 'false' retourneert dan gaat ContezzaRestProxy niet door en retourneert 403

Oplossing 2 moet uiteindelijk deze stappen ook volgen, de verandering zou zijn dat de filter niet gebaseerd op alfresco is maar op AP. Ook let op dat de huidige AP implementatie niet kan weten als de gebruiker toegang heeft (en met welke rechten) tot een bepaalde zaak.

We hebben het volgende afgesproken:

- Contezza Proxy wordt uitgebreid met een filteroptie, waarbij je in je configuratie filters moet instellen.
- De filter kan worden geïmplementeerd in een andere module, namelijk Tezza Services. Dit wordt een Spring Bean.
- De logica gaan we in de code verwerken; we denken nu nog niet na over hoe dit in een configuratiebestand komt, omdat we daar op dit moment niet genoeg overzicht over hebben.
- Een eerste oplossing zou kunnen zijn dat we voor de OpenZaak Proxy alle methodes blokkeren, behalve GET, en deze vervolgens implementeren met een filter.

• FilterRegistryService aangemaakt en geconfigureerd als spring bean:
  • dit verzamelt alle implementaties van interface 'Filter' en bevat een method getFilterByKey om de goede filter op te halen
  • ik heb dit vanuit tezza-services getest, een bean gedefinieerd in de xml context van tezza-services was correct beschikbaar in de registry
• flow van webscript ContezzaRestProxy aangepast om filters toe te passen:
  • als een filter is gedefinieerd in de configuratie maar bestaat niet in FilterRegistryService -> return 500 en log error
  • als de filter wordt toegepast en de request is niet toegestaan -> return 403 en log error
  • als de filter wordt toegepast en de request wordt wel toegestaan -> log debug en normale flow
  • als er geen filter is gedefinieerd dan er is geen wijziging ten opzicht van de huidige flow
• filter toegevoegd in de default configuratie van zrc, met key "zrcFilter"

• basis ZrcFilter implementation aangemaakt (accepteert alle GET request, weigert de rest) en geconfigureerd in xml context

Nog een punt waarmee we geen rekening hebben gehouden:
wat moet gebeuren bij een GET/zaken request? In dit geval is er geen resource uuid in de url en ook niet in de body (er is geen body), ideaal zouden we de response moeten uitfilteren maar dit is duidelijk niet realistisch.
De snelste oplossing zou zijn om alle requests die geen resource uuid bevatten uit te filteren.

Voor get zaken zou je alles kunnen laten zien wat geen vertrouwelijke zaken zijn.

Dus alle zaken door alle pagina's ophalen, filteren, en weer pagination toepassen. Dit lijkt me geen 'proxy' meer.
Ik zou deze functionaliteit in een webscript laten blijven.

• filters gemarkeerd als required=false in registry service
• webscript foutmeldingen verbeterd met gebruik van WebScriptException

1. De request wordt geweigerd als het is naar endpoint zaken/uuid en het is niet GET
2. de uuid van de target zaak is gelezen vanuit de request met de volgende logica:
   • als de endpoint heeft de vorm zaken/uuid of zaken/uuid/secondary_path dan de uuid wordt teruggegeven;
   • als het een GET request is en de endpoint 'zaak' als query parameter ondersteunt dan wordt de uuid gelezen vanuit de url van de query parameter 'zaak'
     met name: als er geen zaak uuid gelezen kan worden vanuit de request, dan wordt de request geweigerd (dus GET /zaken wordt altijd geweigerd).
3. De request wordt geaccepteerd als de gebruiker voldoende rechten (leesrechten voor GET requests, anders schrijfrechten) heeft op de node met dezelfde id als de zaak.

Ik heb refactor gedaan en gemerged met dev. Bij volgende deploy staat de gewijzigde contezza proxy met filter op dev.

@Rick de Rooij @Tahir Malik
Hiermee zou ik #30436 kunnen afronden.
Wat is nu de volgende stap ivm https://support.contezza.nl/issues/30905#note-15 en #31066?
Mijn voorkeur zou zijn om wat nu klaar is te releasen (want in #30436 ligt er best wat werk en die blijft nu hangen) en de volgende stap apart op te pakken.

Besproken met Diego:

• refactored code release 0.3.0 (7.x) en 1.0.0 (23.x) - Rick
• ContezzaRestProxy logica verplaatsen naar RestProxyService, met uitzondering van encryption en filter - Diego
• Tezza Services Zaken get webscript (javascript) vervangen met Java backed class die rest proxy service gebruikt (zonder filter). Je krijgt repsone entity terug van the rest proxy service, daarin moet je itererwen over response data en valideren of authenticated user permississie heeft https://git.contezza.nl/develop/alfresco/contezza-reports/-/blob/main/platform/src/main/java/nl/contezza/reports/webscript/SearchPost.java?ref_type=heads - Diego
• Bestaande parameters komen te vervallen i.v.m. security - Diego

Vervolgstappen in https://support.contezza.nl/issues/30905#note-19 worden opgepakt in #31218