An entity is a structured representation of something that participates in a digital identity or authorization system. It can represent a person, organization, service, device, thing, AI agent, document, application, or other resource. The representation lets a system recognize an actor or resource, retain relevant facts about it, and reason about its relationships to other entities. section 1.1 section 4.3.2
Entities make authorization decisions meaningful. A request asks whether a principal may perform an action on a resource; both the principal and resource are entities. Attributes such as department, owner, classification, tenant, role, and employment status supply the facts that policy conditions evaluate. Relationships, such as ownership, team membership, or management, provide another basis for deciding access. section 4.3.2 section 12.2 section 7.6
A workable entity model separates several concerns:
- Identity: represent the people, services, devices, and agents that can act as principals. section 1.1 section 12.2
- Resources: represent the documents, records, projects, cost centers, applications, and pipelines on which actions occur. section 4.3.2 section 12.2
- Properties: attach typed attributes that policies can inspect, rather than relying on inconsistent source-specific labels. section 12.2 section 9.2.3
- Relationships: model connections such as owner, reader-team membership, or manager supervision as policy-relevant facts. section 7.6 section 9.10
- Names and types: use namespaces and specific entity types to prevent collisions and invalid policy expressions. section 7.4.3 section 9.2.3
Normalize an employee before evaluation
An access decision may need to determine whether an employee can view a document. HR, Finance, and IT can describe the same employee differently—such as active, enabled, or provisioned—so a preprocessing layer must translate those signals into a shared entity schema. The policy engine can then evaluate a stable condition such as principal.employmentStatus == "active" alongside the request’s principal, action, resource, and context. Keeping entities complete, current, and trustworthy is part of producing a reliable decision. section 12.2 section 12.2
Entity design is an architectural and governance choice, not merely a policy-language detail. If separate systems call the same concept owner in one place and createdBy in another, policies and integrations drift. A shared schema, consistent naming, and separate typed attributes make policies easier to read, test, audit, and evolve. When a new entity type is needed, update the schema before writing and testing the policies that use it. section 12.2 section 9.2.3 section 9.10
Figure 12.2 Inside the Policy Decision Point (PDP). The PDP includes more than just a policy engine. At ACME, a signal-processing layer collects data from various systems (HR, Finance, the Customer Authentication Service, device posture clients, and external services like PagerDuty) and organizes it into well-formed entities for evaluation by the Cedar engine. The PDP then provides a decision to the PEP after policies are assessed against the collected context.
This PDP view shows how source signals are collected and shaped into well-formed entities before Cedar evaluates policies and returns a decision for enforcement. section 12.2
