OpenFGA v1.21.0 is een patroon voor de vraag die inloggen nooit beantwoordt: mag deze technicus dit object van deze klant aanraken?

OpenFGA v1.21.0 is een patroon voor de vraag die inloggen nooit beantwoordt: mag deze technicus het object van deze klant aanraken?

De realiteit van een MSP: veel klant-tenants, technici met per klant verschillende delegaties en machine-integraties die zelfstandig handelen. Na de authenticatie is de echte vraag: ‘mag dit subject deze actie uitvoeren op dit object in deze tenant?’ Een token, een groepsclaim of een uitlogevent beantwoordt die vraag niet; een beslispunt wel. Het project dat hier besproken wordt, is een referentiepatroon, geen aanbeveling: OpenFGA, repository openfga/openfga, Apache-2.0, sinds 28 oktober 2025 een CNCF Incubating-project (aangenomen op 14 september 2022), door de maintainers beschreven als een krachtige autorisatie- en permissie-engine, geïnspireerd door Google Zanzibar.

Op 5 oktober 2026 toonde de GitHub-repository 5920 sterren en een laatste push op 2 oktober 2026. Release v1.21.0, gepubliceerd op 20 september 2026, vermeldt één toevoeging, Dynamic Conditions, die het project als experimenteel markeert. Op 6 oktober 2026 volgde een nieuwere release, v1.22.0. Dit artikel beweert niet dat enig Altovar-product OpenFGA gebruikt.

De rest van het stuk behandelt hoe relatiegebaseerde autorisatie aansluit op de tenantstructuur van een MSP, welk pin- en supplychainbewijs de releases bieden, wat OpenFGA niet is (admission policy, netwerkoverlay, scanners) en zes controles voor het beheren van elk centraal beslispunt. Inloggen, uitloggen en tokengeldigheid zijn input; het recht op toegang is een beslissing die bij elk verzoek wordt genomen.

Volgens de eigen beschrijving en topics van de repository is OpenFGA een autorisatie- en permissie-engine, geïnspireerd door Google Zanzibar. De topics noemen relatiegebaseerde toegangscontrole naast RBAC, ABAC en beleidsgebaseerde toegang, plus ‘entitlements’. Dit artikel houdt zich aan die bronnen: het biedt geen functiematrix, geen doorvoer- of latentiecijfers en geen lijst van gebruikers.

ReBAC in Zanzibar-stijl betekent in kopertaal dat rechten worden afgeleid uit relaties tussen subjecten en objecten (wie lid is van welke tenant, welke locatie bij welke tenant hoort, welke technicus gedelegeerd is voor welke locatie) in plaats van uit een lange lijst rollen die in elk token wordt gekopieerd. De beslissing doorloopt de relatiegraaf. Ze plakt geen rollencatalogus in elke JWT.

Governance, volgens de CNCF-projectpagina gelezen op 5 oktober 2026: op 14 september 2022 aangenomen bij de CNCF, sinds 28 oktober 2025 Incubating. Incubating is een volwassenheidsniveau in een stichtingsproces. Het is geen beveiligingscertificering en geen supportcontract. Een MSP die ‘CNCF Incubating’ leest als ‘geaudit voor onze klanten’, leest een stichtingslabel als een klantgarantie die het niet biedt.

Op 5 oktober 2026 had de repository 5920 GitHub-sterren en 511 forks. Sterren zijn een populariteitssignaal, geen beoordeling. De CNCF-pagina toont aparte LFX-statistieken met een ander aantal sterren; dit artikel gebruikt het GitHub-cijfer en haalt de twee niet door elkaar. De licentie die de repository opgeeft, is Apache-2.0.

De recente releases: v1.22.0 op 6 oktober 2026, v1.21.0 op 20 september 2026, v1.20.0 op 8 september 2026 en v1.19.0 op 25 augustus 2026. Geen ervan is gemarkeerd als pre-release. De pinregel om te herhalen: draai v1.21.0 of nieuwer en niets ouder, met v1.22.0 als beter doel voor nieuwe uitrol omdat die een beveiligingsupdate van een afhankelijkheid toevoegt. Volg in een klantomgeving geen zwevende latest-image zonder een changeticket dat de tag noemt.

De ondergrens is niet simpelweg ‘de nieuwste’. v1.20.0 bevatte een Security-sectie: een CVE-fix in de toolchain, een opnieuw gebouwde health-probe-afhankelijkheid en een fix voor één OpenFGA-advisory in het ListUsers-pad. Alles ouder dan v1.20.0 mist die fixes; v1.21.0 bouwt erop voort. v1.22.0 voegt nog een Security-item toe: een bijgewerkte gRPC-bibliotheek die GO-2026-6443 oplost. De zin die een MSP in een ticket kan zetten, is: ‘v1.20.0 bracht beveiligingsfixes, waaronder één OpenFGA-advisory in het ListUsers-pad; draai ≥ v1.21.0, bij voorkeur v1.22.0.’

Dynamic Conditions vraagt om precieze bewoording. De releasenotes van v1.21.0 noemen het ‘een nieuwe experimentele functie’ (onze vertaling): experimenteel, niet algemeen beschikbaar. De rechtenlogica van klanten mag niet afhangen van een experimentele functie, tenzij de klant dat risico uitdrukkelijk schriftelijk aanvaardt.

Releasebewijs dat een MSP aan een changeticket kan hangen, zoals vermeld bij de releases v1.21.0 en v1.22.0: beide zijn als onveranderlijk (immutable) gemarkeerd en elk levert ondertekende checksumbestanden, een in-toto-attestatie en een SBOM per binair archief. Dat bewijs ondersteunt dat het uitgerolde artefact overeenkomt met wat het project heeft gepubliceerd en dat u een componentenlijst hebt. Het is geen audit van de code of van uw autorisatiemodel.

De vraag, één keer opgeschreven en hergebruikt: subject · actie · object · tenant. Een technicus, een partneraccount, een klantgebruiker en een machine-integratie zijn vier soorten subjecten. ‘Lezen’, ‘wijzigen’, ‘exporteren’ en ‘verwijderen’ zijn verschillende acties. Een apparaat, een mailbox en een back-upset zijn objecten. Elk object hoort bij precies één klant-tenant. Die vierdelige vraag is wat een inlogevent op zichzelf nooit beantwoordt.

Relaties in plaats van gekopieerde rollen: een tenant bevat locaties of organisaties; resources horen bij een locatie; een technicus is met een locatie verbonden via een delegatie die in tijd beperkt kan zijn; een klantbeheerder is alleen met de eigen tenant verbonden. Het beslispunt leidt ‘mag deze technicus deze mailbox wijzigen?’ af door die relaties te doorlopen.

Waarom dat de MSP helpt: het recht op toegang verlaat het token en de duizenden verspreide if-controles in applicatiecode en wordt één plek die je kunt inspecteren, testen en loggen. De delegatie van een technicus voor één klant intrekken betekent één relatie verwijderen, niet in elke app tokens opnieuw uitgeven. De wijziging heeft een eigenaar en een audittrail in één opslag.

Het defensieve kader: standaard weigeren, minimale rechten en een controle bij elk verzoek (OWASP Authorization Cheat Sheet). Gebrekkige toegangscontrole (broken access control), inclusief toegang tot objecten van een andere tenant, is de foutklasse die dit patroon moet verminderen. Een uitlog- of intrekkingssignaal kan een nieuwe controle activeren; het beslispunt is de plek waar die controle plaatsvindt. Daarom is uitloggen op zichzelf ook geen intrekking op tenantniveau.

Gatekeeper en Kyverno zijn Kubernetes-admission policies voor infrastructuurobjecten. Ze beslissen of een manifest een cluster in mag, niet of een technicus de mailbox van een klant mag lezen. Geen van beide vervangt het andere. Een MSP die admission policy en applicatierechten door elkaar haalt, zet de verkeerde controle in de verkeerde laag.

OpenZiti is een zero-trust-netwerkoverlay. Het beslist welke identiteiten welke diensten op het netwerk kunnen bereiken; het beslist niet over applicatierechten per object. Bereikbaarheid op het netwerk en rechten op een object zijn verschillende poorten.

Trivy, Syft en DefectDojo zijn scanners, SBOM-generatoren en tools voor het bundelen van bevindingen. Ze beschrijven wat er in uw software zit en wat eraan mankeert. Ze autoriseren geen verzoeken.

Dit artikel zegt niet dat Auris, of een ander Altovar-product, OpenFGA gebruikt, inbouwt of integreert. OpenFGA wordt genoemd als opensource-referentiepatroon voor centrale autorisatie.

Zes verdedigende controles voor het beheren van elk centraal beslispunt, elk met wat als bewijs telt en wat niet.

Ten eerste, inventaris: welke stores en autorisatiemodellen er bestaan, per klant of gedeeld, en wie ze mag wijzigen. Bewijs is een geëxporteerde lijst en een eigenaar per model. ‘Wij gebruiken ReBAC’ is geen bewijs. Ten tweede, pinnen: ≥ v1.21.0 vastgelegd in het changeticket, met het resultaat van de checksum- en attestatiecontrole als bijlage. Een aantal sterren of een latest-tag is geen bewijs.

Ten derde, bescherm de beslissings-API zelf: alleen geauthenticeerde aanroepers, alleen bereikbaar vanuit de applicatielaag, beheerhandelingen beperkt tot benoemde operators met MFA. Ten vierde, modelwijzigingen zijn codewijzigingen: beoordeeld, geversioneerd en vóór de uitrol getest met expliciete deny-gevallen tussen tenants. Bewijs is een testrun die laat zien dat tenant B het object van tenant A niet kan bereiken. ‘Het model compileert’ is geen bewijs.

Ten vijfde, maak back-ups van de relatiegegevens en zet ze terug; oefen een herstel. Een beslispunt dat zijn relaties kwijt is, faalt open of dicht, en beide zijn storingen. Ten zesde, log beslissingen en modelwijzigingen naar de SIEM als operationele signalen, zoals onverwachte modelwijzigingen of pieken in weigeringen na een release. Tot slot: houd experimentele functies buiten de rechtenpaden van klanten totdat het project ze anders classificeert.

Kort samengevat: Apache-2.0; CNCF Incubating sinds 28 oktober 2025; 5920 GitHub-sterren op 5 oktober 2026; pin-ondergrens v1.21.0 (20 september 2026), met v1.22.0 (6 oktober 2026) als beter doel; de beveiligingsfixes van v1.20.0 liggen daaronder; Dynamic Conditions is experimenteel. Gatekeeper, Kyverno, OpenZiti, Trivy, Syft en DefectDojo zijn geen vervanging voor een centraal beslispunt in de applicatie. Inloggen, uitloggen en tokengeldigheid zijn input; het recht op toegang is een beslissing die bij elk verzoek wordt genomen.

Dit artikel beweert niet dat Auris OpenFGA gebruikt. Het patroon is opensource-referentiearchitectuur voor de MSP-vraag die authenticatie op zichzelf nooit beantwoordt.