An entity store is the authoritative data source for authorization decisions. It holds principals, resources, and other entities together with their attributes and relationships, which policies query during evaluation. section 9.4
The store supplies dynamic facts while Cedar policies provide static decision logic. A Policy Decision Point (PDP) gathers the relevant policies, entities, and request context, then passes a coherent view to Cedar rather than relying on scattered application checks. section 9.10 section 9.4
Entity-store designs can use several representations:
- Directory services, graph databases, relational tables, or flat files can provide the underlying store. section 9.4
- A relationship graph represents employees, customers, teams, and documents as nodes, with membership and ownership as edges. section 9.4
- The chosen model affects policy expressiveness and evaluation performance. section 9.4
Team-based document access
A document can point to a customer readers team instead of containing individual customers. The entity store records team membership, allowing a Cedar policy to permit viewing when the requesting customer belongs to that team. Employee access can separately use an employee readers team or the document owner’s manager relationship. section 9.3.1
permit(
principal is ACME::Customer,
action == ACME::Action::"doc:view",
resource is ACME::Document
)
when {
principal in resource.customer_readers_team
};
permit(
principal is ACME::Employee,
action == ACME::Action::"doc:view",
resource is ACME::Document
)
when {
principal in resource.employee_readers_team
|| resource.owner.manager == principal
};
Compare separate Cedar policies that query customer and employee team relationships, while keeping principal types explicit. section 9.3.1
