8 Policy languages and frameworks

This chapter introduces several major authorization policy languages and frameworks by following ACME Corp’s growth from a small company into a complex, distributed organization. As the company’s needs change, different systems prove useful in different settings: XACML for early centralized access control, OPA/Rego for cloud-native infrastructure policy, OpenFGA for relationship-driven collaboration, and AWS IAM for deeply integrated cloud authorization. The chapter uses these examples to show that no single approach fits every scenario; the right choice depends on the kind of authorization problem being solved and the environment in which it must operate.

It then compares the systems through the PARC lens of principal, action, resource, and context. XACML models everything as attributes and supports rich ABAC-style decisions, but its XML verbosity and heavy tooling made it hard to adopt. Rego is far more flexible and works well for general policy enforcement across modern infrastructure, but it leaves principals, actions, and resources largely unstructured, placing more burden on policy authors. OpenFGA takes the opposite path by making relationships the core of authorization, which makes it ideal for sharing and delegation but less suited to contextual or attribute-heavy decisions. AWS IAM, by contrast, is highly expressive within AWS because it is tightly bound to AWS identities, actions, resources, and condition keys.

The chapter’s main takeaway is that authorization systems are shaped by tradeoffs in structure, portability, expressiveness, and developer experience. Cedar is presented as a more balanced option, combining typed entities, structural scoping, and strong expressiveness in a portable, developer-friendly form. ALFA shows how XACML can be made more approachable without changing its semantics, and AuthZEN is described as a complementary standard for the request-and-response interface between enforcement and decision points. Overall, the chapter argues that selecting a policy language should start with the authorization model you need, the platform you use, and the complexity your team can comfortably manage.

OPA (left) vs. Cedar (right) policy evaluation flow. OPA evaluates all policies using the full input, with no built-in filtering based on principal, action, or resource. In contrast, Cedar policies can declare structural scope, allowing the engine to filter policies before evaluation. This improves performance and ensures that only relevant policies are considered.

 Relationship-based access in OpenFGA. This example shows how OpenFGA encodes permissions as logical paths through structured relationships, allowing dynamic and delegatable access without altering the underlying policy logic.

Strength map comparing five policy languages and frameworks (XACML, OPA/Rego, OpenFGA, AWS IAM, and Cedar) across the four PARC elements and portability. Darker shading indicates stronger, more native support for that element; lighter shading indicates partial or minimal support. This visual emphasizes how each system’s design highlights different aspects of authorization, from attribute-rich context handling to typed principals and explicit resource modeling.

• Over the years, a variety of policy languages and frameworks have been developed to handle different needs.
• XACML pioneered standardized ABAC but saw limited adoption due to wordiness and complexity; ALFA emerged to make it more approachable.
• OPA/Rego brings flexible, general-purpose policy-as-code to cloud-native systems and is often used for Kubernetes admission control and microservice authorization.
• OpenFGA implements a relationship-based model inspired by Zanzibar, ideal for sharing and delegation scenarios.
• AWS IAM is deeply integrated with AWS services, making it the default choice for in-cloud authorization, but it’s not portable beyond AWS.
• Applying PARC reveals how each system emphasizes different aspects of authorization, providing guidance on which might fit best in a particular environment.
• Selecting an authorization framework is partly dictated by factors beyond your control, such as the cloud vendor you use or the software you purchase.
• Most organizations will end up using a mix of authorization frameworks and languages.

FAQ