What is Cedarling?

Cedarling in one sentence

Cedarling is an embeddable, self-contained policy decision point built on the Rust Cedar engine.

It runs close to the software that must make an authorization decision, including browsers, mobile apps, backend services, API gateways, databases, and sidecars. Your application remains responsible for enforcing the result before the protected action occurs.

Read the official Cedarling overview for the authoritative component and deployment model.

The decision Cedarling makes

For each request, Cedarling evaluates whether an action on a resource is allowed in the current context.

Cedar calls the four parts of an authorization request principal, action, resource, and context—P-A-R-C. Cedarling evaluates those facts against the Cedar policies and entities loaded for the application, then returns ALLOW or DENY with a request identifier and available diagnostics.

The policy decision point and policy enforcement point have different responsibilities:

1. The application gathers current identity and business facts.
2. Cedarling evaluates the authorization request.
3. Cedarling returns a decision without performing the protected operation.
4. The application enforces that decision before any effect occurs.

Supply identity evidence

Token-based authorization is the recommended starting point for most production deployments in the official authorization reference.

Your application passes one or more mapped JWTs. Cedarling accepts configured token types from trusted issuers, validates their signatures and required claims, and exposes the validated token entities to policies through context.tokens. The JavaScript API calls this authorizeMultiIssuer, but a request may contain one token and does not require more than one issuer. Token-based requests do not treat one token as a conventional Cedar principal.

Application-established authorization uses authorizeUnsigned. It is for flows where the host application has already authenticated the principal or no token is available. The application supplies the principal and related entities directly, and Cedarling evaluates policy without validating a JWT. This mode makes the caller responsible for their authenticity.

Model and author a policy store

At initialization, Cedarling loads an application-specific policy store.

The store contains Cedar policies, a schema, and metadata. It may also contain policy templates, default entities, trusted JWT issuer configuration, and custom issuer configuration. A policy store belongs to one application boundary; it is not a global bucket for every policy in an organization.

The directory-based format keeps the source readable and reviewable:

• metadata.json identifies and versions the store.
• schema.cedarschema or schemas/ defines the principals, actions, resources, context, and entity attributes policies may use.
• policies/ contains the Cedar permit and forbid policies.
• templates/ contains optional Cedar policy templates.
• entities/ contains optional stable entities available to every request.
• trusted-issuers/ contains optional JWT issuer and token-mapping configuration.
• custom-issuers/ contains optional configuration for registered non-JWT token processors.

Use either the root schema file or the split schema directory, not both. Package the directory contents at the archive root when producing the .cjar consumed by Cedarling. See the policy-store reference for the exact fields and archive format.

Authoring flow

1. Name the protected business actions and resource types.
2. Define the principal, resource, and context attributes required to decide them.
3. Write the Cedar schema so invalid policy and entity shapes can be rejected.
4. Author narrowly scoped permit and forbid policies.
5. Validate the schema and policies together before packaging the store.
6. Review and version the source, then build the deployable .cjar.

Policies and schema can be written directly with Cedar tooling. Agama Lab Policy Designer provides a visual authoring path for schemas, policies, and trusted identity providers.

Keep request-specific principals and resources in the runtime request. Use default entities only for stable data that is valid for every request handled by that policy store.

What Cedar contributes

Cedar is the policy language and evaluation model Cedarling uses. Policies state when a principal is permitted or forbidden to perform an action on a resource under defined conditions.

If no permit policy matches, the request is denied; if a matching forbid policy applies, it overrides permits. Schema validation helps catch policy and entity-shape mistakes before deployment; the schema is not itself a source of permission.

The Cedar authorization guide explains permit, forbid, and default-deny evaluation in detail.

Follow one decision end to end

Consider a commerce application protecting ApproveRefund on a refund resource:

Stage	Responsibility
Model	The schema declares the refund action, resource attributes such as amount and tenant, and any context required by policy.
Policy	A permit policy allows an authorized refund reviewer under the approved business conditions; a forbid policy can block a higher-risk condition.
Request	The application sends current token evidence or an application-established principal, the action, the refund resource, and request context.
Decision	Cedarling validates the supplied evidence, evaluates applicable policies, and returns ALLOW or DENY.
Enforcement	The application performs the refund only after ALLOW. DENY and evaluation failures leave the protected operation untouched.

Deploy near enforcement

Cedarling can run in-process or as a sidecar. Placing it close to enforcement reduces the gap between policy evaluation and the code that owns the protected operation.

Deployment	How Cedarling runs
Browser	The WASM npm package evaluates decisions inside a JavaScript application.
Mobile	Native bindings embed Cedarling in iOS and Android applications.
Backend	Language bindings embed Cedarling in services, gateways, and other trusted runtimes.
Sidecar	A separate Dockerized Flask service exposes an AuthZen authorization API to a nearby application.

Embedded applications call their binding directly. A sidecar keeps Cedarling in a separate process and adds a local network boundary that must be authenticated and restricted like any other service endpoint. In both forms, the host application remains the enforcement point.

A browser-side decision may shape the user experience, but it must not authorize a server-side resource; the trusted service that owns that resource must enforce its own decision.

Operate the decision lifecycle

1. Load bootstrap configuration and the versioned policy store when the application starts.
2. Load trusted-issuer metadata and verification keys when token-based authorization is configured.
3. Supply current request facts through the authorization request. Dynamic shared data can be pushed through Cedarling's data interface and exposed under context.data with an optional lifetime.
4. Call token-based or application-established authorization.
5. Treat DENY as a valid policy outcome and handle configuration, validation, or runtime failures separately.
6. Enforce the result before performing the protected action.
7. Retain only the decision and system logs required for operations and audit. Never log raw tokens, secrets, or unnecessary sensitive request data.
8. Release runtime resources according to the lifecycle of the selected binding.

Cedarling keeps decision and system logs in memory for local retrieval. Enterprise deployments can deliver those logs to Janssen Lock Server for centralized retention, review, and downstream security analysis. Policy distribution and log delivery still require authenticated transport and explicit access controls.

What Cedarling is not

Cedarling is a policy decision point, not an identity provider. It does not present a login flow or authenticate a person by itself.

It does not enforce an application action automatically; your code must honor the decision. It also does not query business systems during every evaluation. Supply current facts in the request or through the data interface instead of hiding application data access inside policy evaluation.

Try it safely

Most Cedarling.dev Playground samples use application-established principals. Google Trusted Identity is the controlled token-based example: it uses a site-configured Google OpenID Connect flow and keeps the returned ID token only in the current browser tab. Never paste tokens, secrets, customer data, or production policy material into a sample.

Next steps

• Run a local Playground example.
• Install the JavaScript package.
• Browse Cedarling tutorials.