Zanzibar / OpenFGA は認可関係をデータとして表す
Google Zanzibar と、その考え方を実装した OpenFGA 系では、認可を application code 内の if user.IsAdmin() の集合としてではなく、principal と resource の関係を独立したデータモデルとして表現する。
Zanzibar は Google 内の多数のサービスに対して uniform data model と configuration language を提供し、digital object への access-control list を保存・評価する global authorization system として設計された。
OpenFGA ではこの発想が user, relation, object の relationship tuple として明示される。
user:anne --editor--> document:roadmap
公式ドキュメントでは user, relation, object を relationship tuple の基本要素とし、authorization model と tuples の組み合わせで relationship が direct / implied に存在するかを判定する。
ここで重要なのは、relationship tuple 自体は application code が安全に resource を操作できるという proof object や capability object ではないことである。OpenFGA の Check は「この user と object の間に、この relation が成立するか」を問い合わせるモデルであり、その結果を application がどう保持し、後続コードへどう渡すかは別の設計問題として残る。
したがって、
relationship data
↓ Check
allowed / denied
↓ application-defined bridge
business logic
という境界がある。
「認可済みリソース型」は既存研究の直訳ではなく設計上の合成 のように EditableDocument を生成する設計を採用するなら、OpenFGA はその wrapper の生成条件を決める external authorization source にはなれるが、wrapper そのものを提供するわけではない。
この分離は Cedar の PARC は resource を認可問い合わせの一級要素にする と比較すると分かりやすい。Zanzibar/OpenFGA は relationship graph を中心に置き、Cedar は個々の authorization request を principal × action × resource × context として中心に置く。