coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/infospace/assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md
tegwick 372f671eef
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Distribute frozen federation corpus by concept destination 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
2026-09-06 00:44:37 +02:00

4.7 KiB
Raw Blame History

OpenFGA Modeling

Source Type

Product documentation and open-source implementation reference for OpenFGA authorization modeling (Zanzibar-inspired).

Domain

Relationship-based access control modeling, authorization schema design, and multi-tenant permission systems.

Why This Source Matters

OpenFGA provides a concrete, documented modeling language for Zanzibar-style relationship tuples with authorization models, stores, and checks.

Key Concepts

  • Authorization model: declarative schema of types, relations, and permission definitions.
  • Type definition: object type with relations and optional define rules.
  • Relation: named edge on a type; may allow direct assignment or computed rules.
  • Define / rewrite rules: union (+), intersection, exclusion, and inheritance (from relation).
  • Tuple: user:type#relation@object:type stored fact.
  • Userset: indirect reference such as user:anne#member@group:engineering.
  • Store: isolated tuple set with its own model.
  • Check / ListObjects / ListUsers: query APIs.
  • Contextual tuples: ephemeral tuples supplied at check time.
  • Conditions: CEL-based contextual rules on relations (newer versions).

Relevant Terminology

Term Source meaning
User (in tuple) Subject identifier in user: namespace.
Object Entity in object: namespace with type.
Relation Named permission edge on a type.
Type Schema class for objects (document, folder, organization).
Model Collection of type definitions.
Store Isolated authorization dataset.
define Computed relation rule.
from Inheritance from related object's relation.
contextual tuple Runtime-only tuple for conditional checks.

Modeling Assumptions

  • Model-first design: relations are declared in schema before tuples are written.
  • User and object IDs are opaque strings; no embedded identity semantics.
  • Organization/tenant patterns are modeled as types (e.g., organization, tenant) with member, admin relations.
  • Inheritance chains (folder contains document) are common modeling pattern.
  • Store isolation provides multi-tenant authorization separation.
  • Identity management is external; OpenFGA consumes identifiers.
  • Permissions are computed, not stored as standalone grants.

Identity-Canon Implications

  • OpenFGA aligns with Zanzibar mappings; adds explicit authorization model as schema artifact (downstream, not canonical).
  • Type definitions like organization#member parallel Organization + Membership Relationship but in authz projection.
  • Store maps to Authorization Domain Scope or tenant-scoped authz partition.
  • user: prefix in tuples maps to Authorization Principal identifier.
  • Contextual tuples support request-time Delegation context without persisting relationship.
  • Model examples for parent-child org hierarchies support S03, S04, S05.
  • Reinforces P6: tuples are projections from actors/relationships.

Terminology Conflicts

  • User: OpenFGA user: is tuple subject prefix, not human or account.
  • Organization type: authz type ≠ Organization collective actor unless explicitly linked.
  • Member relation: authz member ≠ community member without model alignment.
  • Store vs. Tenant: store is authz isolation; tenant is broader scope.
  • Permission vs. Relation: permissions are computed from relations; products often say "permission" for relation name.

Candidate Canonical Mappings

OpenFGA concept Candidate canonical concept
Tuple Relationship Tuple (authorization projection)
user: (subject) Authorization Principal
object: (entity) Authorization Resource
Relation Relationship type (authz-implied)
Type definition Authorization schema (downstream)
Store Authorization Domain Scope
define/from rules Authorization derivation (non-canonical)
organization#member Membership Relationship (projection)
organization#admin Administration Relationship (projection)
contextual tuple Delegation context (ephemeral)

Open Questions

  • Should canon document standard OpenFGA type patterns (org/team/resource) as downstream recommendations only?
  • How should principal identifiers be aligned with Account IDs vs. Authenticated Subject sub values?
  • Do conditional (CEL) relations require canonical Context as a first-class projection?
  • Should one Store always map 1:1 to a Tenant Scope?

References