OpenFGA v1.21.0 är ett mönster för den fråga som inloggning aldrig besvarar: får denna tekniker röra denna kunds objekt?

OpenFGA v1.21.0 är ett mönster för den fråga som inloggning aldrig besvarar: får den här teknikern röra den här kundens objekt?

Verkligheten för en MSP är många kundtenanter, tekniker med olika delegeringar hos varje kund och maskinintegrationer som agerar på egen hand. Efter autentiseringen är den verkliga frågan: ”får det här subjektet utföra den här åtgärden på det här objektet i den här tenanten?” En token, ett gruppanspråk eller en utloggningshändelse besvarar den inte; en beslutspunkt gör det. Projektet som diskuteras här är ett referensmönster, inte en rekommendation: OpenFGA, repot openfga/openfga, Apache-2.0, ett CNCF Incubating-projekt sedan den 28 oktober 2025 (antaget den 14 september 2022), som underhållarna beskriver som en högpresterande motor för auktorisering och behörigheter inspirerad av Google Zanzibar.

Den 5 oktober 2026 visade GitHub-repot 5920 stjärnor och en senaste push den 2 oktober 2026. Version v1.21.0, publicerad den 20 september 2026, listar ett enda tillägg, Dynamic Conditions, som projektet märker som experimentellt. En nyare version, v1.22.0, kom den 6 oktober 2026. Den här artikeln påstår inte att någon Altovar-produkt använder OpenFGA.

Resten av texten går igenom hur relationsbaserad auktorisering passar MSP:ns tenantstruktur, vilka belägg för versionslåsning och leveranskedja versionerna ger, vad OpenFGA inte är (admission policy, nätverksoverlay, skannrar) och sex kontroller för att driva valfri central beslutspunkt. Inloggning, utloggning och tokens giltighet är indata; behörigheten är ett beslut som fattas vid varje begäran.

Enligt repots egen beskrivning och ämnestaggar (topics) är OpenFGA en motor för auktorisering och behörigheter inspirerad av Google Zanzibar. Taggarna nämner relationsbaserad åtkomstkontroll tillsammans med RBAC, ABAC och policybaserad åtkomst, plus ”entitlements”. Den här artikeln håller sig till de källorna: den ger ingen funktionsmatris, inga siffror för genomströmning eller latens och ingen lista över användare.

ReBAC i Zanzibar-stil betyder, på köparspråk, att behörigheter härleds ur relationer mellan subjekt och objekt (vem som är medlem i vilken tenant, vilken plats som hör till vilken tenant, vilken tekniker som är delegerad till vilken plats) i stället för ur en lång lista roller som kopieras in i varje token. Beslutet går igenom relationsgrafen. Det klistrar inte in en rollkatalog i varje JWT.

Styrning enligt CNCF:s projektsida, läst den 5 oktober 2026: antaget i CNCF den 14 september 2022, Incubating sedan den 28 oktober 2025. Incubating är en mognadsnivå i en stiftelseprocess. Det är varken en säkerhetscertifiering eller ett supportavtal. En MSP som läser ”CNCF Incubating” som ”granskat för våra kunder” läser en stiftelseetikett som en kundgaranti som den inte ger.

Den 5 oktober 2026 hade repot 5920 GitHub-stjärnor och 511 forkar. Stjärnor är en popularitetssignal, inte en bedömning. CNCF-sidan visar separata LFX-mått med ett annat antal stjärnor; den här artikeln använder GitHub-siffran och blandar inte ihop de två. Licensen som anges i repot är Apache-2.0.

De senaste versionerna: v1.22.0 den 6 oktober 2026, v1.21.0 den 20 september 2026, v1.20.0 den 8 september 2026 och v1.19.0 den 25 augusti 2026. Ingen av dem är märkt som förhandsversion. Låsregeln att upprepa: kör v1.21.0 eller nyare och inget äldre, med v1.22.0 som bättre mål för nya utrullningar eftersom den lägger till en säkerhetsuppdatering av ett beroende. Följ inte en flytande latest-image i en kundmiljö utan ett ändringsärende som namnger taggen.

Golvet är inte bara ”den senaste”. v1.20.0 hade ett Security-avsnitt: en CVE-rättning i verktygskedjan, ett ombyggt beroende för hälsokontrollen och en rättning av en OpenFGA-säkerhetsbulletin i ListUsers-sökvägen. Allt äldre än v1.20.0 saknar de rättningarna; v1.21.0 bygger vidare på dem. v1.22.0 lägger till ytterligare en Security-post, ett uppdaterat gRPC-bibliotek som åtgärdar GO-2026-6443. Meningen som en MSP kan skriva i ett ärende är: ”v1.20.0 innehöll säkerhetsrättningar, bland annat en OpenFGA-bulletin i ListUsers-sökvägen; kör ≥ v1.21.0, helst v1.22.0.”

Dynamic Conditions kräver noggranna formuleringar. Versionsanteckningarna för v1.21.0 beskriver den som ”en ny experimentell funktion” (vår översättning): experimentell, inte allmänt tillgänglig. Kundernas behörighetslogik bör inte bero på en experimentell funktion, om inte kunden uttryckligen och skriftligen accepterar den risken.

Versionsbelägg som en MSP kan bifoga ett ändringsärende, så som de listas för versionerna v1.21.0 och v1.22.0: båda är märkta som oföränderliga (immutable), och var och en levereras med signerade kontrollsummefiler, en in-toto-attestering och en SBOM per binärarkiv. Det stöder att artefakten du driftsatte motsvarar det projektet publicerade och att du har en komponentlista. Det är ingen granskning av koden eller av din auktoriseringsmodell.

Frågan, skriven en gång och återanvänd: subjekt · åtgärd · objekt · tenant. En tekniker, ett partnerkonto, en kundanvändare och en maskinintegration är fyra sorters subjekt. ”Läsa”, ”ändra”, ”exportera” och ”radera” är olika åtgärder. En enhet, en brevlåda och en säkerhetskopieuppsättning är objekt. Varje objekt hör till exakt en kundtenant. Den fyrdelade frågan är vad en inloggningshändelse aldrig besvarar på egen hand.

Relationer i stället för kopierade roller: en tenant innehåller platser eller organisationer; resurser hör till en plats; en tekniker är kopplad till en plats genom en delegering som kan vara tidsbegränsad; en kundadministratör är bara kopplad till sin egen tenant. Beslutspunkten härleder ”får den här teknikern ändra den här brevlådan?” genom att gå igenom de relationerna.

Varför det hjälper MSP:n: behörigheten lämnar token och de tusentals utspridda if-kontrollerna i applikationskoden och blir ett ställe som kan granskas, testas och loggas. Att återkalla en teknikers delegering hos en kund är en borttagen relation, inte nyutfärdade tokens i varje app. Ändringen har en ansvarig och ett granskningsspår i ett och samma lager.

Den defensiva ramen: neka som standard, minsta möjliga behörighet och en kontroll vid varje begäran (OWASP Authorization Cheat Sheet). Bristande åtkomstkontroll (broken access control), inklusive åtkomst till objekt i en annan tenant, är den felklass som mönstret ska minska. En utloggning eller en återkallelsesignal kan utlösa en ny kontroll; beslutspunkten är där den kontrollen sker. Det är också därför en utloggning i sig inte är en återkallelse på tenantnivå.

Gatekeeper och Kyverno är admission policies i Kubernetes för infrastrukturobjekt. De avgör om ett manifest får komma in i ett kluster, inte om en tekniker får läsa en kunds brevlåda. Inget av dem ersätter det andra. En MSP som blandar ihop admission policy med applikationsbehörighet lägger fel kontroll i fel lager.

OpenZiti är ett nätverksoverlay för nollförtroende (zero trust). Det avgör vilka identiteter som kan nå vilka tjänster i nätverket; det avgör inte applikationsbehörigheter per objekt. Nåbarhet i nätverket och behörighet till ett objekt är olika grindar.

Trivy, Syft och DefectDojo är skannrar, SBOM-generatorer och verktyg för att samla fynd. De beskriver vad som finns i din programvara och vad som är fel med den. De auktoriserar inga begäranden.

Den här artikeln säger inte att Auris, eller någon annan Altovar-produkt, använder, bäddar in eller integrerar OpenFGA. OpenFGA nämns som ett referensmönster med öppen källkod för central auktorisering.

Sex försvarskontroller för att driva valfri central beslutspunkt, var och en med vad som räknas som belägg och vad som inte gör det.

För det första, inventering: vilka lager och auktoriseringsmodeller som finns, per kund eller delade, och vem som får ändra dem. Belägg är en exporterad lista och en ansvarig per modell. ”Vi använder ReBAC” är inget belägg. För det andra, versionslåsning: ≥ v1.21.0 registrerad i ändringsärendet, med resultatet av kontrollsumme- och attesteringskontrollen bifogat. Ett antal stjärnor eller en latest-tagg är inget belägg.

För det tredje, skydda själva besluts-API:et: endast autentiserade anropare, nåbart endast från applikationslagret, administrativa åtgärder begränsade till namngivna operatörer med MFA. För det fjärde, modelländringar är kodändringar: granskade, versionshanterade och testade före utrullning med uttryckliga neka-fall mellan tenanter. Belägg är en testkörning som visar att tenant B inte kan nå tenant A:s objekt. ”Modellen kompilerade” är inget belägg.

För det femte, säkerhetskopiera och återställ relationsdata; öva en återställning. En beslutspunkt som har tappat sina relationer fallerar antingen öppen eller stängd, och båda är avbrott. För det sjätte, logga beslut och modelländringar till SIEM som driftsignaler, till exempel oväntade modelländringar eller toppar i antalet nekanden efter en version. Och till sist: håll experimentella funktioner borta från kundernas behörighetsvägar tills projektet klassar dem annorlunda.

Kort sagt: Apache-2.0; CNCF Incubating sedan den 28 oktober 2025; 5920 GitHub-stjärnor den 5 oktober 2026; lägsta version v1.21.0 (20 september 2026), med v1.22.0 (6 oktober 2026) som bättre mål; säkerhetsrättningarna i v1.20.0 ligger under; Dynamic Conditions är experimentell. Gatekeeper, Kyverno, OpenZiti, Trivy, Syft och DefectDojo ersätter inte en central beslutspunkt i applikationen. Inloggning, utloggning och tokens giltighet är indata; behörigheten är ett beslut som fattas vid varje begäran.

Den här artikeln påstår inte att Auris använder OpenFGA. Mönstret är referensarkitektur med öppen källkod för den MSP-fråga som autentisering i sig aldrig besvarar.