Skip to content
pg-extensions research

Current architecture

pg_permissions provides an authorization store and check engine in one Postgres schema. RBAC manages roles and assignments. OpenFGA manages authorization models and relationship tuples. Cedar manages policies, templates and entities. All three share subject identity and expose functions for application checks. Row level security (RLS) is an optional enforcement integration.

Separate model APIs

Section titled “Separate model APIs”

The rbac_*, fga_* and cedar_* tables and functions follow the rules of their own models. Each model retains its semantics and performance optimizations. An RBAC assignment does not create an OpenFGA tuple or a Cedar entity; applications manage each model’s data explicitly.

The research compared three earlier implementations: a tuple core (A), a policy-first evaluator (B), and a compiled model (C). Those experiments exposed differences in what a generic role or deny meant. The project chose per-model tables (D) on 2026-10-29 and promoted that implementation to pg_permissions--0.0.1.sql.

Cedar (design E) extends that architecture in pg_permissions--0.1.0.sql. It is part of the same extension, alongside RBAC and OpenFGA. Existing databases can upgrade from 0.0.1 while keeping their roles, models and tuples.

Shared identity and application checks

Section titled “Shared identity and application checks”

The extension does not store users or depend on an auth schema. It reads the current subject from JWT claims or transaction-local settings. Client functions answer for that subject; admin functions manage data or evaluate an explicit subject.

The backend can use these functions as its authorization API, checking access before performing an operation and combining model decisions when needed. A Cedar forbid overrides Cedar permits; it does not automatically override a grant from RBAC or OpenFGA. The backend must implement any deny across models in its combined decision. See Application checks.

Optional RLS enforcement

Section titled “Optional RLS enforcement”

An application can also call the same functions from RLS policies on a table. Permissive policies grant access through any model; restrictive policies can deny access across them. A Cedar policy defines a model rule and works independently of these Postgres table policies.

Read policies can list accessible scopes or IDs once per statement. Write policies check the affected row. Cedar also accepts row attributes in cedar_is_authorized_current, so a policy can evaluate columns without storing a second copy of them as an entity. The RLS guides explain these choices and their performance implications.

Conditions and compatibility

Section titled “Conditions and compatibility”

OpenFGA conditions use a CEL subset implemented in PL/pgSQL. The extension compiles expressions when it writes a model and evaluates them against tuple and request context. Current-subject helpers accept no request context and deny access that depends on a condition they cannot evaluate.

Cedar accepts policies as text or JSON and evaluates them against entities, their attributes and their hierarchy. Its admin check accepts request context and temporary entities. The current-subject functions accept no request context and deny access when a relevant forbid fails to evaluate. This behavior applies to application checks and RLS alike.

Pinned upstream test suites check OpenFGA and Cedar behavior. They do not imply support for every feature of the upstream services or libraries. Read OpenFGA compatibility, CEL support, and Cedar compatibility. Cedar targets 4.14; schema validation and partial evaluation are outside its scope.

Future models

Section titled “Future models”

A new model can add its own tables, management and check APIs, compatibility statement, tests and optional RLS integration while using the existing subject identity. Its documentation should explain its concepts and limits alongside the other models. Cedar is the first addition to the original RBAC and OpenFGA implementation; the earlier policy-first prototype remains historical research.

Evidence and design details

Section titled “Evidence and design details”