List Authorizationは単一ResourceへのCan()の繰り返しでは設計しきれない
単一Resourceの認可は Can(principal, view, document) で表せても、List endpointは「候補集合から見えるResourceだけを効率よく返す」という別種の問題を持つ。pagination、sort、filter、結果件数まで絡むため、取得後に1件ずつCanするだけでは性能やpage semanticsが崩れやすい。
SpiceDBはList endpoint保護を独立した問題として説明し、主に LookupResources、CheckBulkPermissions、materialized local viewの3方式を挙げる。LookupResourcesはaccessible resourceが比較的小さい場合に使いやすいが、公式docsでは1万件を超える規模で重い処理になりうるとしている。OpenFGAにもListObjectsとBatch Checkがあり、model complexityやtuple数によって性能特性が大きく変わる。
したがってApplication Protocolには、単一Resource用の Can() と別にList向けのauthorization strategyを持つ必要がある場合がある。
候補をDBで絞る → Bulk Check → 許可分だけ返す
許可IDをLookup → DB queryへpredicateとして渡す
認可indexをmaterialize → query時にjoin/filter
Resource Hierarchyの上位scopeで一度だけcheckできる場合はさらに単純化できる。Google AIP-132のListもparent collectionをrequestの中心に置いている。ただし「parentを見られれば全childを見られる」というpolicyが本当に成立する場合に限る。
List Authorizationは「Permission abstractionが失敗した」のではなく、authorization queryの方向が逆になった問題と捉えるとよい。単体CheckはResource→可否、ListはPrincipal+Permission→Resource集合である。
Search Authorizationは検索集合と認可集合のIntersection問題になる はfilter/sortが加わるさらに難しいケースを扱う。