An authorization policy is a declarative rule that decides whether a principal may take an action on a resource under stated conditions. Rather than burying permission checks in application code, it makes the decision logic explicit, reviewable, and evaluable at runtime. A policy commonly expresses the same core question: who can do what, to which resource, and when or under which contextual facts. section 4.3.2 section 1.5.2
Policies turn business requirements into enforceable access decisions. A temporary external engagement, a required manager approval, or a managed-device requirement can each become a rule without creating another role or changing every service. This is especially useful when access depends on current relationships, resource ownership, time, device state, region, or clearance rather than on a fixed job title alone. section 1.5.2 section 6.0
A policy contract has three main parts:
- Effect: the outcome, such as permit or forbid. section 7.2
- Scope: the principals, actions, and resources to which the rule applies. section 7.2
- Conditions: contextual or identity-based facts that must hold, such as ownership or device management. section 7.2.4
Owner access on a managed device
A policy can permit an employee to view or edit a document when the employee owns it and is using a managed device. The effect grants access; the scope limits the rule to employee document actions; the conditions match owner to principal and require device trust. Separating these concerns keeps a security requirement understandable without scattering checks through the application. section 7.2.4 section 9.0
Multiple policies may be evaluated for one request. In attribute-based access control (ABAC), static rules receive changing attribute values as inputs: a principal’s clearance, a resource owner’s department, the hour, network risk, or on-call status. Policies can be layered, combining baseline safeguards with action- or resource-specific rules. This flexibility requires accurate, fresh attribute data and tooling that can explain which rules affected a decision. section 6.2.1 section 6.2.3
Policy management is an operational and governance practice, not merely rule writing. A Policy Administration Point (PAP) can centralize authoring, review, versioning, testing, deployment, and later audit. Decision logs can record the request, result, and contributing inputs, while policy owners and approval processes remain necessary to make the controls accountable. section 4.4.2 section 1.5.4
Figure 7.1 A complete Cedar policy showing effect (top box), scope (middle box), and conditions (bottom box)
Inspect the visual separation of effect, scope, and conditions in a complete policy. section 7.2.4
