A principal is the entity making a request in an authorization system. It may be a person, organization, service account, device, machine, or process—not merely a human user. Naming the actor precisely matters because authorization decisions evaluate what that actor may do to a protected resource under particular conditions. section 3.1 section 4.3.1
A principal is distinct from an account, identifier, and subject. An account stores information such as attributes, credentials, and roles; an identifier uniquely identifies that account. The principal usually is the subject represented in an account, but delegation can separate them: a parent acting for a child is the principal, while the child is the subject. section 3.1
Figure 3.1 Relationships among key identity concepts used in authentication and authorization. A principal (an actor such as a user or service) controls an identifier that uniquely identifies an account. The account stores attributes about a subject, which might be the principal itself or another entity the principal manages.
Use the relationship diagram to distinguish the requesting actor from the account, identifier, and subject represented by authorization data. section 3.1
In the PARC model—principal, action, resource, and conditions—the principal supplies the “who is acting” part of an access decision. Policies can use principal attributes such as department, clearance level, role, group membership, or tenant alongside the requested action, target resource, and runtime context. section 4.3.1 section 12.2
A request is more than a user name
When Alice opens a team report from home at 9:17 p.m., Alice is the principal and viewing is the action. A Policy Enforcement Point (PEP) sends those facts to a Policy Decision Point (PDP), which combines them with device, network, group, and time information. Alice may have the required role and trusted device, yet still be denied because the request occurs outside approved hours. section 4.4.1
Represent principals consistently when building authorization flows:
- Identify the principal from an active session or token before evaluating a protected operation. section 9.8
- Model the principal as a structured entity with reliable attributes and relationships that policies can evaluate. section 12.2
- Normalize source-specific labels into a shared schema; inconsistent terms such as active, enabled, and provisioned can make policy evaluation unreliable. section 12.2
- Treat services, scheduled jobs, and service-to-service calls as possible principals, not as exceptions to authorization. section 1.2.1 section 9.8
Authorization models differ in how they match principals. An access control list (ACL) attaches entries for named principals or groups directly to a resource. Cedar makes principal a defined part of a policy request, while Open Policy Agent (OPA) with Rego leaves the principal’s input structure to the policy author. Flexibility therefore requires explicit constraints and careful testing. section 5.1 section 7.3 section 8.2.3
Figure 9.2 The Policy Enforcement Point (PEP) in ACME’s Customer Collaboration platform translates a real-world /share request into a Cedar evaluation by combining session data (principal), entity data (resource relationships), and context signals (environment attributes). Cedar’s is_authorized API provides an allow or deny decision, which the PEP enforces before forwarding the request to the backend.
Follow how a PEP translates session data into a principal and combines it with action, resource, and context for a Cedar authorization decision. section 9.8
As principal populations grow, direct resource lists become difficult to maintain. Groups can reduce individual entries, but large organizations may still accumulate tens of thousands of groups and require manual corrections. Separating policy decisions, enforcement, policy management, and context retrieval supports more scalable and auditable authorization. section 1.2.1 section 4.7
