OpenFGA 1.19
Last reviewed Sep 19, 2026
Prompt Details
Prompt Composition
1prompt
- OpenFGA 1.19117 lines · 4.2K tokens
CWE Coverage
- 20
- 250
- 287
- 295
- 306
- 319
- 367
- 532
- 639
- 770
- 778
- 807
- 862
- 863
- 942
Prompt Preview
Use these standalone rules for OpenFGA 1.19 deployments using server 1.19.0, authorization models, relationship tuples, and application integrations over HTTP or gRPC. Treat authenticated application users, API clients, model and tuple writers, stores, application data, and cached decisions as separate trust boundaries.
Authorization models
- Keep the model DSL and generated JSON under review; accept model definitions only from authorized policy publishers, and validate them with the deployed server version.
- Define business permissions such as
can_viewas computed relations without direct assignment when all grants must pass through the underlying roles and restrictions. - Specify direct relationship type restrictions narrowly;
[user],[group#member], and[user:*]admit different subject forms, and a computed relation without direct types cannot receive direct grants. - Review every
orbranch as an independent grant path; apply mandatory tenant membership, conditions, andbut notexclusions to every path that must enforce them. - Allow
user:*only for deliberately public permissions; it covers the entire subject type and does not establish authentication, tenant membership, or account existence. - Review recursive group membership and
viewer from parentinheritance for unintended grants; enforce application invariants such as one owner, one parent, and same-tenant ancestry in tuple-writing logic.
Subjects, objects, and tenants
- Authenticate the application principal independently and derive the checked user from that identity; OpenFGA API