An action is the operation a principal attempts to perform on a resource. In an authorization request, “view a report,” “edit a document,” or “deploy” is the action; the decision also depends on who requests it, what they target, and which conditions apply. This principal–action–resource–conditions (PARC) model turns a vague access question into a testable request. section 4.3.1 section 7.3
Actions should name meaningful operations rather than merely imply broad access. Common actions include read, write, update, and delete, while applications can define domain-specific operations such as ShareWithFriend or ApplyPhotoFilter. API actions commonly correspond to endpoint verbs, so action names become part of the authorization vocabulary shared by applications and policies. section 4.3.1
An authorization system evaluates an action in context:
- Identify the principal attempting the operation, such as a person, service account, or device. section 4.3.1
- Resolve the protected resource, which may be a document, database row, folder, account, or API endpoint. section 4.3.1
- Apply conditions such as time, device trust, location, risk score, or workload identity before permitting the action. section 4.3.1
- Match the requested operation against policy and enforce an allow or deny decision before the backend proceeds. section 9.8
Document sharing request
A user clicking Share creates a document-sharing action, not a general statement that the user “has access.” A Policy Enforcement Point (PEP) identifies the active-session principal, maps the UI operation to doc:share, resolves the target document, gathers context such as managed-device status and time, and sends those values to Cedar. The result controls whether the request reaches the backend. section 9.2.1 section 9.8
Static access control lists (ACLs) attach allowed actions directly to a resource. When a principal requests an operation, the system checks whether a matching individual or group entry authorizes that action; a missing entry or denied operation blocks access. ACLs can support allow and deny entries, groups, wildcards, and inherited permissions, but their decisions remain tied to the resource’s list. section 5.1 section 5.1.1
Policy frameworks differ in how strongly they structure actions. Cedar schemas can declare actions and constrain the principal, resource, and context that each accepts. XACML represents actions as string-valued attributes, leaving naming consistency to policy authors. OPA and Rego likewise commonly receive an unconstrained input.action string, making careful policy writing and testing important. section 8.1.2 section 8.2.3 section 9.2.1
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 real /share operation is translated into principal, action, resource, and context before Cedar returns an enforceable decision. section 9.8
