Cedar の PARC は resource を認可問い合わせの一級要素にする
Cedar は authorization request を principal, action, resource, context の4要素として定義し、PARC と略している。公式リファレンスでは P, A, R は entity reference、C は record である。
Can this principal
take this action
on this resource
in this context?
この形の価値は、resource を HTTP request の雑多な属性や application-specific な暗黙値にせず、principal / action と同格の authorization input として固定することにある。
Cedar schema は application が認識する principal、resource、action の entity type と構造を宣言できる。action の appliesTo では、その action に対して許される principal type / resource type / context shape を指定できる。policy validator は schema を使って policy の型的な不整合を検出できる。
また Cedar の best practice は、principal や resource に属する情報を context へ押し込まないよう明示的に勧めている。context は request 固有の情報、たとえば時刻、HTTP header、device posture などに使うものとされる。
これは「resource-based authorization をどうコードへ表すか」という問いに対して、少なくとも authorization boundary では
Principal
Action
Resource
Context
を別々の typed concept として扱うべきだ、というかなり明確な設計例になる。
ただし Cedar の設計は 型システムで「認可ポリシーを守るコード」を検証する研究 や Object-Capability は authority を参照の到達可能性で表す と逆向きでもある。Cedar 論文は authorization logic を application code に埋め込むのではなく、policy を code から分離して authorizer に decision を委譲することを設計目標としている。したがって Cedar は「認可済み resource 型を application 内で持つ」方式を直接支持するものではない。
「認可済みリソース型」は既存研究の直訳ではなく設計上の合成 を採るなら、PARC の Allow を wrapper/capability 生成境界へ接続する、というのは application 側の追加設計になる。