Policy Language - Revision history

Tom: /* Existing Languages */

2026-03-22T23:24:23Z

‎Existing Languages

Tom: /* Cedar */

2026-03-22T23:17:24Z

‎Cedar

Tom: /* Graph Query Lanage */

2025-09-16T00:26:29Z

‎Graph Query Lanage

Tom: /* Compare Cedar to Rego */

2025-09-15T23:49:24Z

‎Compare Cedar to Rego

Tom: /* Compare Cedar to Rego */

2025-09-15T23:46:29Z

‎Compare Cedar to Rego

Tom: /* Graph Query Lanage */

2025-09-15T23:44:02Z

‎Graph Query Lanage

Tom: /* Existing Languages */

2025-09-15T23:33:42Z

‎Existing Languages

Tom: /* Cedar */

2025-09-07T01:45:18Z

‎Cedar

Tom: /* Open Policy Agent */

2025-08-24T23:15:29Z

‎Open Policy Agent

Tom: /* Current Activity */

2025-08-10T23:56:45Z

‎Current Activity

@@ Line 11: / Line 11: @@
 ==Existing Languages==
 Originally these languages were all written by geeks, and for geeks. What is needed is some policy that works in a real-world user journey.  In other words, the user needs to be able to understand what is expected and when. It might be that a [[Policy Language]] can be a meta language that can be translated into commonly used language so that the user can understand the impact of the policy, or it might be that the [[Policy Language]] is only used to move the policy from one machine to another, but even then debugging would be easier if the [[Policy Language]] could be rendered into something that a human could understand.
 ===Formal Proofs===
 Iteration is powerful, but it blows up the state space of a policy. Once you allow unbounded loops, it becomes computationally intractable — sometimes outright impossible — to exhaustively explore every possible execution path. That means you can’t reliably prove universal statements like:

@@ Line 37: / Line 37: @@
 * [https://www.cedarpolicy.com/en Cedar Policy Language website.]
 * [https://www.linkedin.com/events/7254252166016614400/comments/ Cedarling Launch]
 news:
 * 2025-08-21  [https://aws.amazon.com/about-aws/whats-new/2025/08/amazon-verified-permissions-cedar-4-5/ Amazon Verified Permissions now supports Cedar 4.5]

← Older revision		Revision as of 00:26, 16 September 2025
Line 113:		Line 113:

	So: Rego is like a Swiss Army knife for policy enforcement across many domains, while Cedar is a specialist scalpel for access control in AWS.		So: Rego is like a Swiss Army knife for policy enforcement across many domains, while Cedar is a specialist scalpel for access control in AWS.
		+
		+	===Cedarling===
		+
		+	Cedarling: An Embeddable Policy Decision Point
		+
		+	Cedarling is an open-source, embeddable Policy Decision Point (PDP) that runs anywhere—from the browser or mobile app to sidecars or cloud services—returning fine-grained authorization decisions based on Amazon’s Cedar policy syntax and the open-source Cedar Rust engine.
		+	# Core Capabilities
		+	Policy Evaluation*: Converts incoming JWTs into Cedar entities (principal, action, resource, context) and evaluates them against declarative access policies using the PARC model (Policy, Action, Resource, Context).
		+	JWT Validation: Trusts and validates tokens from configured issuers, ensuring only well-formed, unexpired, unrevoked tokens drive authorization decisions.
		+	Audit Logging: Emits detailed decision logs—denied or allowed—with tokens, policies, contexts, and timestamps, feeding SIEM or ITDR platforms for real-time threat detection.
		+	# Architecture & Modules == Cedarling’s Rust-based codebase is organized into key modules for flexibility and performance:
		+	authz*: Core policy evaluation logic
		+	entity_builder*: Maps JWT claims to Cedar entities
		+	jwt*: Signature, issuer, and expiration checks
		+	log*: Structured audit logging
		+	bootstrap_config & init*: Load and initialize configuration
		+	http*: Multi-target safe HTTP helpers for policy updates and revocation checks
		+	lock*: (Optional) Communicates with a “Lock Server” for dynamic policy pushes and telemetry
		+	tests*: End-to-end coverage ensuring correctness
		+	# Performance & Use Cases
		+	Ultra-Low Latency*: Typically issues authz decisions in under 50 microseconds, making it suitable for high-volume, latency-sensitive environments.
		+	Legacy Instrumentation*: Can be injected into existing applications without altering business logic—evaluating requests and logging decisions risk-free.
		+	Cloud-Native & Edge*: Ideal for zero-trust scenarios, from API gateways and Kubernetes clusters to databases and IoT gateways.
		+	# Ecosystem & Adoption
		+	Janssen Project*: Cedarling is a core PDP within the Linux Foundation’s Janssen open-source IAM suite (alongside OAuth/OIDC, SCIM, FIDO modules).
		+	Gluu Flex*: Commercial distributions embed Cedarling for enterprise deployments, integrating with OAuth status lists and centralized threat-detection workflows.
		+	Third-Party Integrations*: Used by platforms like StrongDM for zero-trust access and by SaaS vendors via Cedar-agent for standalone PDP functionality.
		+
		+	In essence, Cedarling brings Amazon Cedar’s expressive, purpose-built authorization language into a lightweight, embeddable Rust library—enabling consistent, auditable access control at any layer of your architecture.*

	===Graph Query Lanage===		===Graph Query Lanage===

@@ Line 85: / Line 85: @@
 **  Otherwise, access is denied.
 *Flexibility:** You can add more rules, combine attributes, or pull in external JSON data.
 *Amazon Cedar**
-### **Amazon Cedar**
+ cedar
-```cedar
+ // Define a policy template
-// Define a policy template
+ permit(
      principal in Role::"admin",
      action == Action::"delete",
      resource in Resource::"server"
-);
+ );
-```
 *How it works:**
 ** Cedar policies are written in terms of **principals** (who), **actions** (what), and **resources** (on what).

@@ Line 63: / Line 63: @@
   Example Policy: “Only users with the role `admin` can delete resources”
-### **Rego (OPA)**
+Rego (OPA)**
-```rego
+* rego
-package example.authz
+ package example.authz
   Input is JSON, e.g.:
+  {
@@ Line 114: / Line 113: @@
 So: **Rego** is like a *Swiss Army knife* for policy enforcement across many domains, while **Cedar** is a *specialist scalpel* for access control in AWS.
 ===Graph Query Lanage===

@@ Line 57: / Line 57: @@
 https://medium.com/@bhavini_sehgal/exploring-role-based-access-control-rbac-and-rego-a-simplified-guide-to-policy-management-932db0fcdf97
 ===Graph Query Lanage===
 https://graphql.org/
 ===Cardea===

@@ Line 40: / Line 40: @@
 * 2025-08-21  [https://aws.amazon.com/about-aws/whats-new/2025/08/amazon-verified-permissions-cedar-4-5/ Amazon Verified Permissions now supports Cedar 4.5]
 * 2025-06-17  [https://aws.amazon.com/blogs/opensource/introducing-cedar-analysis-open-source-tools-for-verifying-authorization-policies/ Introducing Cedar Analysis: Open Source Tools for Verifying Authorization Policies]
 ===Rego===
-Rego is extremely expressive. It’s almost Turing-complete, with the ability to iterate over arbitrary collections, perform recursion, and generate new data structures at runtime. This flexibility is a big reason OPA has been adopted widely in infrastructure-as-code validation, Kubernetes admission control, and API authorization. If you need to traverse complex nested JSON or write sophisticated matching logic, Rego can do it — and often in a very natural way for developers.
+Rego is a high‑level declarative policy language created for the Open Policy Agent (OPA). Inspired by Datalog, it’s designed to work with structured data (like JSON). Rego is extremely expressive. It’s almost Turing-complete, with the ability to iterate over arbitrary collections, perform recursion, and generate new data structures at runtime. This flexibility is a big reason OPA has been adopted widely in infrastructure-as-code validation, Kubernetes admission control, and API authorization. If you need to traverse complex nested JSON or write sophisticated matching logic, Rego can do it — and often in a very natural way for developers.
 https://www.openpolicyagent.org/docs/latest/policy-language/
@@ Line 51: / Line 61: @@
 https://graphql.org/
 ===Cardea===

@@ Line 51: / Line 51: @@
 ===Open Policy Agent===
 [https://www.openpolicyagent.org/ OPA, the Open Policy Agent]
 * Declarative. Express policy in a high-level, declarative [[Policy Language]] that promotes safe, performant, fine-grained controls. Use a language purpose-built for policy in a world where JSON is pervasive. Iterate, traverse hierarchies, and apply 150+ built-ins like string manipulation and JWT decoding to declare the policies you want enforced.
 * Context-aware. Leverage external information to write the policies you really care about. Stop inventing roles that represent complex relationships that years down the road no one will understand. Instead, write logic that adapts to the world around it and attach that logic to the systems that need it.

@@ Line 94: / Line 94: @@
 * [https://learn.microsoft.com/en-us/previous-versions/dotnet/articles/bb530196(v=msdn.10)?redirectedfrom=MSDN Managing Group Policy ADMX Files Step-by-Step Guide]
-==Current Activity==
+===PAM===
 ===IETF===