Tutorial
What is Cedarling?
Learn what Cedarling does, how it uses Cedar policies and trusted identity evidence, what a policy store contains, and where enforcement belongs.
On this page
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.
What question does Cedarling answer?
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 the request against the Cedar policies and entities loaded for the application and returns ALLOW or DENY with a request identifier and available diagnostics.
Two ways to 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 checks them against configured trusted issuers and validation rules, maps claims to Cedar entities, and makes token data available to policies. The JavaScript API calls this authorizeMultiIssuer, but a request may contain one token and does not require more than one issuer.
Application-established authorization is for flows where the host application has already authenticated the principal or no token is available. The application supplies the principal directly, and Cedarling evaluates policy without validating a JWT. This mode makes the caller responsible for the principal’s authenticity.
What is in a policy store?
At initialization, Cedarling loads an application-specific policy store.
The store contains Cedar policies and a schema, and may also contain default entities and trusted-issuer configuration. Trusted-issuer entries identify issuers and token mappings Cedarling may use for token-based authorization.
A policy store belongs to one application boundary; it is not a global bucket for every policy in an organization. See the policy-store reference for the supported formats and fields.
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.
Where enforcement belongs
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.
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.
The decision lifecycle
- Initialize Cedarling and load the policy store.
- Build a request with the action, resource, context, and the identity-evidence mode your application uses.
- Call token-based or application-asserted authorization.
- Treat DENY as a valid policy outcome and handle SDK or runtime failures separately.
- Enforce the result before performing the protected action.
- Record only the diagnostics you need, and never log tokens, secrets, or sensitive request data.
- Shut down the Cedarling client when its lifecycle ends.
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.
Most Cedarling.dev Playground samples use application-established principals. Google Trusted Identity is the controlled exception: 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 any sample.