A permit policy grants access when its scope matches the request and its conditions evaluate to true. Cedar combines applicable policies using deny-overrides: any matching forbid wins, while an unmatched or false permit leaves the request denied by default. section 7.3.3 section 7.2.1
Design permit policies around explicit authorization boundaries:
- Scope the principal, action, and resource narrowly so each rule remains readable, testable, and less likely to become too broad. section 9.3.1
- Express access conditions through attributes and relationships, such as team membership or a document owner's manager. section 9.3.1 section 9.3.3
- Pair positive grants with forbid guardrails when constraints must override otherwise valid access, such as unmanaged devices or invalid delegation. section 9.3.3 section 18.6.3
Document viewing by team membership
A customer permit allows document viewing when the customer belongs to the document's customer readers team. A separate employee permit covers the employee readers team or the owner's manager, avoiding a single broad policy with branching type logic. 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
};
Cedar permit snippets show separate customer and employee scopes for the same document-view action. section 9.3.1
