Contezza Community » Tezza

plan uittekenen (samen met Bram) over hoe we de groepenconstructie gaan doen voor de authenticatiematrix.

• groepen in groepen.
• deze groepen kunnen gemaakt worden door FB's vanuit de admin tools.
• deze groepen hebben rechten voor de users aan boord.
• deze groepen zijn uiteindelijk gebaseerd op alfresco rechten (consumer, coordinator, manager, contributor).

meeting voor morgen (21/6) ingeschoten

Uit gesprek met Tjerk maak ik het volgende op:

• We gebruiken de Permissie groepen van Alfresco (Consumer, Contributor, Collaborator, Manager)
• Elk Zaaktype krijgt een eigen site met daarin alleen de zaken van het bijbehorende Zaaktype
• Een autorisatieprofiel bevat:
  • Permissie groep Alfresco
  • Lijst van gebruikers die bij deze groep horen
  • Lijst van Sites(zaaktypen) waar dit profiel op van toepassing is.

Sites krijgen deze autorisatiegroep toegevoegd.

• Permissiegroep: CONSUMER
• Lijst van gebruikers:
  • Tjerk
  • Bram
  • Nume
    Lijst van Zaaktypen:
• Melding Openbare Ruimte
• Incident Melding

Dit betekent dat als Autorisatiegroep 'Adviseur' op de Sites voor Melding Openbare Ruimte en Incident Melding wordt toegevoegd (met rol CONSUMER) Tjerk, Bram en Nume alleen leesrechten hebben op zaken binnen deze Site.

• Permissiegroep: CONTRIBUTOR
• Lijst van gebruikers:
  • Tjerk
  • Tahir
  • Rick
    Lijst van Zaaktypen:
• Melding Openbare Ruimte
• Bestemmingsplan Opstellen

Dit betekent dat als Autorisatiegroep 'Behandelaar' op de Sites voor Melding Openbare Ruimte en Bestemmingsplan Opstellen wordt toegevoegd (met rol CONTRIBUTOR) Tjerk, Tahir en Rick lees- en bewerkrechten hebben op zaken binnen deze Site. Tjerk heeft nu op Melding Openbare Ruimte ook bewerkrechten verkregen, terwijl hij eerder vanuit Autorisatieprofiel 'Adviseur' alleen leesrechten had.

Dit betekent wel dat uiteindelijk er een migratie van Zaken naar bijbehorende sites moet komen. En dat wanneer er een nieuw zaaktype wordt toegevoegd hier ook een Site voor wordt gemaakt.

• Onderstaande doen
  • nieuwe ticket voor Maaike zodat ze alvast op basis van de autorisatie matrix al dingen aan een uit kan gaan zetten
• 2 nieuwe permissions in de permissionDefinitions.xml
  • Behandelaar & Downloader --> Reviewen of het engels of NL moet. Engels zou dan kunnen zijn CaseManager & CanDownload
    

          <!-- A collaborator can do anything that an editor and a contributor can do -->
          <permissionGroup name="Collaborator" allowFullControl="false" expose="true">
             <includePermissionGroup permissionGroup="Editor" type="cm:cmobject" />
             <includePermissionGroup permissionGroup="Contributor" type="cm:cmobject" />
          </permissionGroup>
    
           <!-- A collaborator can do anything that an editor and a contributor can do -->
           <permissionGroup name="Behandelaar" allowFullControl="false" expose="true">
             <includePermissionGroup permissionGroup="Collaborator" type="cm:cmobject" />
          </permissionGroup>
    
          <!-- A collaborator can do anything that an editor and a contributor can do -->
          <permissionGroup name="Downloader" allowFullControl="false" expose="true">
             <includePermissionGroup permissionGroup="Consumer" type="cm:cmobject" />
          </permissionGroup>
    
          <!-- A contributor can create content and then they have full permission on what -->
          <!-- they have created - via the permissions assigned to the owner.              -->
          <permissionGroup name="Contributor" allowFullControl="false" expose="true">
             <!-- Contributor is a consumer who can add content, and then can modify via the -->
             <!-- owner permissions.                                                      -->
             <includePermissionGroup permissionGroup="Consumer" type="cm:cmobject" />
             <includePermissionGroup permissionGroup="AddChildren" type="sys:base" />
             <includePermissionGroup permissionGroup="ReadPermissions" type="sys:base" />
          </permissionGroup>
    
          <!-- An editor can read and write to the object; they can not create    -->
          <!-- new nodes. They can check out content into a space to which they have       -->
          <!-- create permission.                                                          -->
          <permissionGroup name="Editor" expose="true" allowFullControl="false">
             <includePermissionGroup type="cm:cmobject" permissionGroup="Consumer" />
             <includePermissionGroup type="sys:base" permissionGroup="Write" />
             <includePermissionGroup type="cm:lockable" permissionGroup="CheckOut" />
             <includePermissionGroup type="sys:base" permissionGroup="ReadPermissions" />
          </permissionGroup>
    
          <!-- The Consumer permission allows read to everything by default.                  -->
          <permissionGroup name="Consumer" allowFullControl="false" expose="true">
             <includePermissionGroup permissionGroup="Read" type="sys:base" />
          </permissionGroup>
    

• Admin-Tools UI aanpassen zodat je 1 groep en 1 persoon heel snel met multi-select/chips aan Sites incl hun rechten kan toevoegen
  • Bijv. je creëert een groep via admin-tools Adviseur, dan wil je daarna de net aangemaakt groep selecteren
  • Sites selecteren
  • Per site aangeven welke rol de gebruiker/groep krijgt of in 1 keer dezelfde rol voor iedere site toekennen

ZaakCreateActionExecuter is zo aangepast dat bij het aanmaken van een nieuwe zaak er een nieuwe Site wordt opgezet met als naam de zaaktype identificatie uit OpenZaak. Indien er al een Site onder die naam bestaat wordt deze site gebruikt. De rest van de opbouw van de zaakstructuur blijft hetzelfde.
Zie branch:
https://git.contezza.nl/develop/products/tezza-services/-/tree/feature/createZaak-zaaktype-sites/%2328339?ref_type=heads

Voor OZ Zaken willen we graag dat Zaken in een eigen Site belanden gebaseerd op Zaaktype --> werk verricht door Bram moet nog geverifieerd worden

• Bram & Roel doen Dev en reviewen
• Tjerk test en doet een functionele test adhv gem Utrecht
• Bram automatische tests schrijven
• Roel technisch testen en uitrollen op de omgevingen

• Bram start alvast aan de ObjectType code aanpassing
• Tjerk en Roel gaan zitten om dit functioneel goed uit te werken
• Onderdeel van dit mini-project is ook de migratie-script om alle Zaken uit de Zaken site te migreren naar de eigen sites voor bestaande klanten

• Keycloack is niet essentieel
  • Je moet lokaal zonder Keycloack ook volledig met Tezza kunnen werken
  • We zetten de profielen voor Keycloack alleen in zodat GZAC hiermee kan werken
  • AP-backend moet een setting hebben wel/geen keycloack
• De AP-backend krijgt een API om voor de huidige ingelogde gebruiker de profielen op te halen
• De AP-backend gaat lokaal via een PostgreSQL DB opslaan welke profielen, met welke rol, met welke zaaktypes zitten
• De AP-frontend wordt verantwoordelijk om alle SiteMembers op te halen van de verschillende Sites
• De AP-frontend wordt verantwoordelijk om alle profielen op te halen uit de AP-backend
• de AP-frontend wordt verantwoordelijk om inzichtelijk te maken welke gebruikers via profielen in het systeem zitten en welke los vanuit Alfresco in een Site of via een Groep zijn toegevoegd
• de AP-backend is verantwoordelijk bij het publiceren om de lijst om-te-katten naar sites membership
  • Sites
  • Rollen bijv. site_contributor
  • Users

1. POST: /api/autorisatieprofielen
   

   {
     "userProfiles": [
       {
         "profileName": "beheerder",
         "role": "site_manager",
         "sites": [
           {
             "siteName": "Zaken" 
           },
           {
             "siteName": "Dossiers" 
           }
         ],
         "users": [
           {
             "username": "gorden" 
           },
           {
             "username": "paul" 
           }
         ]
       },
       {
         "profileName": "bewerker",
         "role": "site_contributor",
         "sites": [
           {
             "siteName": "Zaken" 
           },
           {
             "siteName": "Objecten" 
           }
         ],
         "users": [
           {
             "username": "gorden" 
           },
           {
             "username": "alex" 
           }
         ]
       }
     ]
   }
   

2. Opslaan in de database JSON via JPA en relationele DB
3. Call naar Alfresco POST: /alfresco/api/-default-/public/alfresco/versions/1/sites/{siteId}/members waarbij siteId=zaken
   

   [
     {
       "role": "site_contributor",
       "id": "gorden" 
     },
     {
       "role": "site_manager",
       "id": "gorden" 
     },
     {
       "role": "site_manager",
       "id": "paul" 
     }
   ]
   

4. Voorbeeld code chatgpt
   

   import axios from 'axios';
   
   const ALFRESCO_API_BASE_URL = 'https://your-alfresco-server/alfresco/api/-default-/public/alfresco/versions/1';
   const SITE_ID = 'Zaken';
   const ACCESS_TOKEN = 'your-access-token';
   
   // Gebruikers en rollen die je wilt synchroniseren
   const membersToSync = [
     { role: 'site_contributor', id: 'gorden' },
     { role: 'site_manager', id: 'paul' }
   ];
   
   async function syncSiteMembers() {
     try {
       // 1. Haal bestaande leden op
       const existingMembersResponse = await axios.get(`${ALFRESCO_API_BASE_URL}/sites/${SITE_ID}/members`, {
         headers: {
           Authorization: `Bearer ${ACCESS_TOKEN}`
         }
       });
   
       const existingMembers = existingMembersResponse.data.list.entries.map((entry: any) => ({
         id: entry.entry.id,
         role: entry.entry.role
       }));
   
       console.log('Bestaande leden:', existingMembers);
   
       // 2. Bepaal leden om toe te voegen
       const membersToPost = membersToSync.filter(newMember => {
         return !existingMembers.some(
           existingMember =>
             existingMember.id === newMember.id && existingMember.role === newMember.role
         );
       });
   
       // 3. Bepaal leden om te verwijderen
       const membersToDelete = existingMembers.filter(existingMember => {
         return !membersToSync.some(
           newMember =>
             newMember.id === existingMember.id && newMember.role === existingMember.role
         );
       });
   
       // 4. Voeg ontbrekende leden toe
       if (membersToPost.length > 0) {
         console.log('Toe te voegen leden:', membersToPost);
         await axios.post(`${ALFRESCO_API_BASE_URL}/sites/${SITE_ID}/members`, membersToPost, {
           headers: {
             Authorization: `Bearer ${ACCESS_TOKEN}`,
             'Content-Type': 'application/json'
           }
         });
         console.log('Leden succesvol toegevoegd.');
       } else {
         console.log('Geen nieuwe leden om toe te voegen.');
       }
   
       // 5. Verwijder leden die niet meer in de sync-lijst staan
       for (const member of membersToDelete) {
         console.log(`Verwijderen lid: ${member.id} met rol: ${member.role}`);
         await axios.delete(`${ALFRESCO_API_BASE_URL}/sites/${SITE_ID}/members/${member.id}`, {
           headers: {
             Authorization: `Bearer ${ACCESS_TOKEN}`
           }
         });
         console.log(`Lid ${member.id} succesvol verwijderd.`);
       }
     } catch (error) {
       console.error('Fout bij synchroniseren van leden:', error.response?.data || error.message);
     }
   }
   
   // Start het synchronisatieproces
   syncSiteMembers();
   

5. LETOP! wel goed rekening houden dat gebruikers dus in een profiel

TEST-Feature

Feature: Synchronizing authorization profiles
  As an administrator, I want to create and synchronize authorization profiles,
  so that the associated sites and users are properly set up in Alfresco and Keycloak.

  Background:
    Given the Alfresco API is available
    And Keycloak is available
    And the backend is started with an empty local profile storage

  Scenario: Creating and synchronizing authorization profiles
    Given the frontend sends the following JSON with userProfiles to the backend:
      """ 
      {
        "userProfiles": [
          {
            "profileName": "beheerder",
            "role": "site_manager",
            "sites": [
              {
                "siteName": "Zaken" 
              },
              {
                "siteName": "Dossiers" 
              }
            ],
            "users": [
              {
                "username": "gorden" 
              },
              {
                "username": "paul" 
              }
            ]
          },
          {
            "profileName": "bewerker",
            "role": "site_contributor",
            "sites": [
              {
                "siteName": "Zaken" 
              },
              {
                "siteName": "Objecten" 
              }
            ],
            "users": [
              {
                "username": "gorden" 
              },
              {
                "username": "michaeljohnson" 
              }
            ]
          }
        ]
      }
      """ 
    When the backend processes these profiles
    Then the backend must have stored these profiles locally

    # Check Alfresco memberships:
    When the backend triggers the Alfresco API
    Then the Alfresco site "Zaken" should have the following members:
      | id             | role             |
      | gorden         | site_manager     |
      | paul           | site_manager     |
      | michaeljohnson | site_contributor |

    And the Alfresco site "Dossiers" should have the following members:
      | id     | role         |
      | gorden | site_manager |
      | paul   | site_manager |

    And the Alfresco site "Objecten" should have the following members:
      | id             | role             |
      | gorden         | site_contributor |
      | michaeljohnson | site_contributor |

    # Check Keycloak roles:
    When the backend creates the Keycloak roles
    Then there should be a Keycloak role "beheerder" with the following users:
      | username |
      | gorden   |
      | paul     |

    And there should be a Keycloak role "bewerker" with the following users:
      | username       |
      | gorden         |
      | michaeljohnson |

https://git.contezza.nl/develop/alfresco/contezza-configuratie-services/-/tree/feature/toevoegen-keycloak-calls/%2329673?ref_type=heads

• AP-backend moet een setting hebben wel/geen keycloack
• De AP-backend krijgt een API om voor de huidige ingelogde gebruiker de profielen op te halen
• De AP-backend gaat lokaal via een PostgreSQL DB opslaan welke profielen, met welke rol, met welke zaaktypes zitten
• de AP-backend is verantwoordelijk bij het publiceren om de lijst om-te-katten naar sites membership
  • Sites
  • Rollen bijv. site_contributor
  • - -- - Users

• Alfresco authentication zodat kan worden gewerkt met de ingelogde gebruiker en Alfresco credentials gebruikt kunnen worden voor de applicatie.
• Ophalen van profielen obv Alfresco gebruiker
• Omzetten van de request message naar onderstaande voorbeeld

• Wat doen we met puur functionele profielen (Profielen die bijvoorbeeld worden ingericht voor het toestaan van downloaden)? Eerder was het plan deze alleen op te slaan in Keycloak zodat ze in de headers zichtbaar zouden zijn maar niet gelijk gebruikers op een site zetten.
  • Voorstel: Functionele groepen wel opslaan in DB maar niet doorzetten naar sites bij het publishen.
• In de request worden alle sites op één hoop gegooid. Is dit wenselijk? Wanneer de front-end de profielen ophaalt moet deze nu zelf gaan sorteren wat een Objecten Site is en wat een Zaken Site is (als we dit willen tonen in de UI, voor zo ver ik weet was dit wel het plan).
  • Voorstel: Geef in de post request losse lijsten mee (Zaken sites, Objecten sites, eventueel functionele context). Bij het ophalen van profielen komen er gescheiden lijsten terug.

1. Inloggen in AP-Frontend,
   • Inlog via Keycloack/Basic
   • Check of ik site_tezza_manager ben
2. Haal via AP-Backend alle profielen uit de DB ex. paging
   • Profiel
   • Sites
   • Rol

   • {
             "id": "60343fa6-7c53-4610-8927-aeb92ba994db",
             "name": "Tezza Beheer",
             "role": "SiteManager",
             "users": ["paul"],
             "userGroups": [
                 "GROUP_TEZZA_BEHEER" 
             ],
               "sites": [{
                   "siteShortName":"tezza",
                   "siteType":"alfresco",
                   "siteTitle":"Tezza Beheer",
               }]
             },
             "published": true,
             "protected": true,
         }
     

3. Nieuwe aanmaken
   • Zie voorbeeld JSON hierboven, zonder id
   • Foutmelding als name hetzelfde is
4. Bewerken
   • Geeft de bestaande id mee
   • Force wijzigt het in de Database
5. Delete kan alleen bij niet protected profielen
   • Geen knop in de AP-Frontend
   • Backend doet een check of het profiel protected is, geeft anders een foutmelding
6. Bootstrapped profielen protected=true
   • Tezza Beheer
     • GROUP_ALFRESCO_ADMINISTRATORS
     • site Tezza met rol manager
   • Tezza Postintake
     • GROUP_ALFRESCO_ADMINISTRATORS
     • site Tezza met rol contributor
   • Tezza Gemeente
     • GROUP_ALFRESCO_ADMINISTRATORS
     • site Tezza met rol consumer
   • Create Zaken/Dossier/Object
     • GROUP_ALFRESCO_ADMINISTRATORS
     • GEEN SITE & Geen rol
   • Tezza Toezicht
     • GROUP_ALFRESCO_ADMINISTRATORS
     • GEEN SITE & Geen rol

1. Login Tezza
2. AP-backend call haal mijn profielen op
   • Tezza geeft de keycloack of alfresco ticket mee naar de backend (AP-backend, doet zelf geen extra controle, behalve dat de token/ticket valide is)
     

     { userProfiles: [ "Tezza Beheer", "Tezza Toezicht"]
         }
     

   • Op basis hiervan kan in de UI de knoppen aan/uit gezet worden
3. Indien AP-backend down is, moet Tezza blijven werken zonder foutmeldingen
   • Functionaliteit zoals Create Zaken/dossiers/objecten doet het niet
   • Functionaliteit zoal downloaden doet het niet
   • Rest blijft as-is werken op basis van de Alfresco Site-permissies
   • Snackbar tonen met meer-details bij inloggen als site_tezza_manager (Tezza Beheerder) gebruiker

1. Login Tezza
   • Lees uit de JWT-JSON de ROLES uit
   • Nader onderzoeken als we dit aan het implementeren zijn
   • Indien er geen bearer-token is, dus Basic Auth
     • Call naar AP-backend als proxy naar Keycloack om Rollen op te halen van de ingelogde gebruiker op basis van username
   • Op basis hiervan kan in de UI de knoppen aan/uit gezet worden
2. Indien AP-backend down is, moet Tezza blijven werken zonder foutmeldingen
   • Functionaliteit zoals Create Zaken/dossiers/objecten doet het niet
   • Functionaliteit zoal downloaden doet het niet
   • Rest blijft as-is werken op basis van de Alfresco Site-permissies
   • Snackbar tonen met meer-details bij inloggen als site_tezza_manager (Tezza Beheerder) gebruiker

• Frontend laat via een warning de diff fouten zien van de Profielen vs Site permissions via de Alfresco API
  • Use-case Postintake profiel 4 gebruikers toegevoegd via AP
    • Share ingelogd, 1 gebruiker weg gehaald uit de site
    • Verwachting dat de AP-frontend een warning laat zien dat de profiel niet in sync is met Alfresco
  • Use-case Postintake profiel 4 gebruikers toegevoegd via AP
    • Share ingelogd, 1 gebruiker toegevoegd aan de site
    • Verwachting dat de AP-frontend een warning laat zien dat de profiel niet in sync is met Alfresco

• Frontend laat via een warning de diff fouten zien van overige ZaakType, ObjectType, DossierType sites
  • Use-case gebruiker is lid van 3 ZT Sites, 2 OBJ Sites
    • Share ingelogd, 1 gebruiker toegevoegd of weg gehaald aan de site
    • Verwachting dat de AP-frontend een warning laat zien dat de profiel niet in sync is met Alfresco

Stand van zaken per 10/02/2025:

• Front-end doet diff logica
  • Er wordt een vergelijking gemaakt tussen gepubliceerde profielen en de site memberships. 'Oprhaned users', gebruikers die lid zijn van een zaak maar niet van een profiel, worden weergegeven
• Front-end doet publish logica
  • Bij het publiceren wordt er een payload samengesteld met sites, gebruikers en rollen. Hierin wordt ook besloten of deze moeten worden toegevoegd, verwijderd of aangepast.
• Back-end doet sync met keycloak. Keycloak gebruikers moeten gelijk worden gehouden. Hier komt een aparte methode voor.
• Working copies
  • Back-end maakt het mogelijk om gepubliceerde profielen apart te bewerken via working-copies.
  • Bij het publiceren wordt de working copy de actieve copy
  • Er wordt een tabel bijgehouden met changes per profiel zodat die voor een audit inzichtelijk is.

• De diff dient alleen gedaan worden voor Tezza Sites, dus Zaaktype/Dossies/Objecten
• Purgen van de rechten moet niet een default actie zijn
  • We hebben bijv. gezien dat er met 1 profiel was, terwijl er 5 Sites waren met rechten en dan haalt hij alle rechten eraf
  • Dit moet een expliciete toggle/actie zijn en dan zal hij de rechten purgen
• Initieel zal de diff alleen de sites diff'en uit de profielen
  • Hoe we dit nog moeten verder maken is nog niet bekend, maar goed om dit maandag te bespreken

Tahir Malik wrote:

Na testen van de 1e versie is gebleken

• De diff dient alleen gedaan worden voor Tezza Sites, dus Zaaktype/Dossies/Objecten
• Purgen van de rechten moet niet een default actie zijn
  • We hebben bijv. gezien dat er met 1 profiel was, terwijl er 5 Sites waren met rechten en dan haalt hij alle rechten eraf
  • Dit moet een expliciete toggle/actie zijn en dan zal hij de rechten purgen
• Initieel zal de diff alleen de sites diff'en uit de profielen
  • Hoe we dit nog moeten verder maken is nog niet bekend, maar goed om dit maandag te bespreken

• moet de diff gedaan worden voor (1) Tezza Sites, (2) Zaken/Dossiers/Objecten sites of (3) sites die genoemd worden ergens in een profiel? Deze zijn drie verschillende dingen. Let op: als (3) wordt geimplementeerd, zou dit betekenen dat: als gebruikers worden toegevoegd in een site via een profiel en vervolgens wordt die profiel verwijderd, dan wordt die site niet meer in de diff berekend dus die gebruikers worden niet verwijderd vanuit die site.
• bij het publiceren is het mogelijk om te selecteren welke regels vanuit de diff moeten worden gepubliceerd, dit betekent dat jouw tweede punt is al mogelijk. Mijn voorstel is dus:
  • publicatie actions van type 'delete' weghalen van de default selectie
  • toggles toevoegen in de 'publish' dialog om makkelijker te maken om groepen van actions te selecteren of deselecteren

• Purge moet dus default uit staat
• 5 default profielen moet je niet kunnen verwijderen
• srv_openzaak moet aan de default profiel van Tezza Beheer toegevoerd worden
• Diff moet zoals nu op alles gedaan blijven worden en inzichtelijk gemaakt worden
• De publish zou met de vorige versie moeten checken en de wijzigen publishen ==> bespreken

• Purge staat default uit (delete statements)
• Fixes rondom keycloak:
  • Keycloak profielen worden correct verwijderd wanneer het profiel zelf wordt verwijderd
  • Keycloak profielen worden alleen aangemaakt bij het publishen van profielen
• Bewerken van een profiel is niet langer additief. Bij het verwijderen van gebruiker A en toevoegen van gebruiker B wordt alleen gebruiker B toegevoegd aan de working copy ipv gebruikers A & B
• Site model is aangepast in lijn met User model.
• Wanneer een profiel toegang moet hebben tot alle zaak- of objecttypesites, ook wanneer deze in de toekomst nieuw worden toegevoegd kan er een wildcard '*' worden meegegeven door de front-end.
• Protected profielen zijn niet te verwijderen en velden zijn read-only gemaakt

1. CORS geeft problemen wanneer er lokaal een connectie wordt gelegd met dev-tezza. -> Erik gaat hier naar kijken
2. Default profielen moeten worden uitgebreid met sites en bijbehorende Alfresco groepen.

Tahir Malik wrote:

1. Bootstrapped profielen protected=true
   • Tezza Beheer
     • GROUP_ALFRESCO_ADMINISTRATORS
     • site Tezza met rol manager
   • Tezza Postintake
     • GROUP_ALFRESCO_ADMINISTRATORS
     • site Tezza met rol contributor
   • Tezza Gemeente
     • GROUP_ALFRESCO_ADMINISTRATORS
     • site Tezza met rol consumer
   • Create Zaken/Dossier/Object
     • GROUP_ALFRESCO_ADMINISTRATORS
     • GEEN SITE & Geen rol
   • Tezza Toezicht
     • GROUP_ALFRESCO_ADMINISTRATORS
     • GEEN SITE & Geen rol

Ik mis deze profielen