Skip to main content

Put policy between intent and impact.

Cedarling is an embeddable policy decision point. It evaluates Cedar policies close to the application, agent, API, or service that must enforce an authorization decision.

Three application actions and a Cedar policy store reach the Cedarling policy decision point. Cedarling returns allow or deny, and the application enforces the decision at separate gates.
Cedarling directs the authorization decision. The application remains responsible for enforcing it before impact.

From policy source to an enforced decision.

The policy store defines what Cedarling can evaluate. The host application supplies current request facts and enforces the result before the protected operation runs.

Policy store

Rules to evaluate

Cedarling

Returns a decision

Application

Enforces the result

01

Load a policy store

Package metadata, a Cedar schema, policies, and optional trusted-issuer configuration in the directory-based format.

Policy-store format
02

Evaluate the request

Use validated token evidence or an application-established principal with the action, resource, and context.

Authorization requests
03

Enforce the result

The policy enforcement point permits or blocks the operation. A decision does not enforce itself.

Policy store

Readable source. Deployable archive.

Keep policy-store files readable in source control, then package them as a rootless Cedar archive for Cedarling. Request-specific principals and resources stay in the runtime request instead of becoming static default entities.

Readable files

Cedar archive

.cjar
policy-store/
├── metadata.json
├── schema.cedarschema          # schema option A
├── schemas/                    # schema option B
├── policies/
│   └── access.cedar
├── templates/                  # optional
├── entities/                   # optional default entities
├── trusted-issuers/            # optional
└── custom-issuers/             # optional

Choose one schema layout. The archive contains directory contents at its root; if an imported store contains both layouts, Cedarling uses the rootschema.cedarschema.

Deployment

Put decisions near every enforcement surface.

Embed Cedarling with a language binding or run the pinned sidecar beside a service. Each trusted enforcement point still owns the operation it protects.

JavaScript / WebAssembly

Embed Cedarling in a JavaScript application using its WebAssembly binding.

pnpm add --save-exact @janssenproject/cedarling_wasm@0.0.469

Cedarling Sidecar

Run Cedarling alongside a service and send authorization evaluation requests over HTTP using AuthZen.

Cedarling Sidecar guide

Other language integrations

Use Cedarling from Python, Rust, Go, Java, Kotlin, Swift, or C. Open the language guide for its installation and build requirements.

Cedarling embedded in browser, mobile, and backend applications, alongside a separate application calling a Dockerized Cedarling Sidecar and enforcing its allow or deny decision.
Embedded binding

Cedarling runs inside browser, mobile, and backend applications.

Application code → decision → enforcement

Docker
Flask

Cedarling Sidecar

A Dockerized Flask service powered by cedarling_python.

AuthZen request ↔ ALLOW or DENY

Production architecture

Cedarling is the decision layer.

Add the identity, policy delivery, and operational controls your environment requires around that layer.

Design a production authorization stack
Jans Auth

Trusted identity

Validate mapped tokens from configured issuers, including tokens issued by Jans Auth.

Agama Lab
Git

Controlled policy releases

Author policies with Agama Lab, review them in Git, and deploy versioned policy stores.

Lock Server

Central decision logs

Send Cedarling decision logs to Lock Server for protected operational review.

We use analytics cookies to measure which pages are useful, so we can improve them. They are only set if you accept. Essential cookies needed for the site to work are always on. See our privacy policy.