Skip to main content

Production authorization, built around Cedarling.

Combine Cedarling’s policy decisions with application enforcement, trusted identity, controlled policy releases and centralized decision logs. Integrate these components with your existing infrastructure.

A Cedarling policy decision point inside an application receives signed token evidence and a versioned policy store from external systems. It returns allow or deny to the application's protected operation and sends logs to a centralized store.
Cedarling runs inside the application boundary as the policy decision point. Jans Auth or another trusted issuer supplies signed token evidence. Agama Lab and Git supply a versioned Cedar archive. Cedarling returns allow or deny to the application for enforcement and sends decision, system, and metric logs to Janssen Lock Server.
Jans Auth or trusted OIDC issuer

Signed token evidence

Agama Lab Policy Designer
Git release

Versioned .cjar policy store

Cedarling inside the application

ALLOW or DENY → protected operation

Janssen Lock Server

Decision, system, and metric logs

Enforcement

Application enforcement with Cedarling

Separate authorization rules from application logic while keeping enforcement at the protected operation. Cedarling evaluates requests against policies; your application or gateway permits or blocks access.

Cedarling integration documentation (opens in a new tab)
Cedarling
ALLOW or DENY
Application or gateway
Your application or gateway

Policy Enforcement Point

Owns protected operations, trusted resource data and request context.

Cedarling

Policy Decision Point

Evaluates authorization requests against the loaded policies and returns an allow or deny decision.

Embed Cedarling in the application process or deploy it as a sidecar. Define how the enforcement point handles denied requests, evaluation errors and unavailable decisions.

Identity

Trusted identity with Jans Auth or your existing provider

Use identity evidence from configured trusted issuers in authorization decisions. Jans Auth can provide authentication and token issuance; Cedarling validates configured tokens and makes their claims available to policies.

Trusted issuer and token validation documentation (opens in a new tab)
Jans Auth
Token evidence
Cedarling
Jans Auth or your trusted issuer

Identity and token issuance

Supplies signed claims and issuer metadata under your identity configuration.

Cedarling token validation

Evidence for policy evaluation

Validates mapped tokens against configured trust and claim requirements.

Applications that establish identity themselves can supply application-asserted principals through their trusted enforcement boundary.

Policies

Policy governance with Agama Lab and Git

Author and test authorization policies in Agama Lab Policy Designer. Review changes in Git and release versioned policy stores for deployment to Cedarling.

Agama Lab policy release documentation (opens in a new tab)
Agama Lab
Git
Policy-store release
Cedarling
Agama Lab Policy Designer

Policy authoring and testing

Maintains the schema, policies and test requests for review.

Your Git and release workflow

Versioned policy delivery

Records reviewed changes and publishes versioned policy-store artifacts.

Keep policy authoring and release management separate from runtime evaluation, with a traceable record of the policy version deployed.

Audit

Centralized decision logging with Lock Server

Collect Cedarling decision logs across applications with Janssen Lock Server. Use allowed and denied decisions to investigate access, understand policy behavior and support audit reviews.

Lock Server integration documentation (opens in a new tab)
Cedarling
Decision logs
Lock Server
Cedarling decision logs

Authorization evidence

Captures evaluation outcomes and policy diagnostics.

Janssen Lock Server

Optional centralized collection

Centralizes collection from multiple Cedarling instances using authenticated connections.

Configure authenticated log delivery, retention and access controls to meet your operational requirements.

Responsibility map

Keep every boundary explicit.

A production deployment assigns one owner to each authorization responsibility. Components can change; the boundaries must remain clear.

ResponsibilityTypical owner
Authenticate users and issue tokensJans Auth or another trusted issuer
Author and test Cedar policiesAgama Lab Policy Designer
Review and release policy storesYour Git and release workflow
Evaluate authorization requestsCedarling
Enforce ALLOW or DENYYour application, API, gateway, or service
Collect decision logsLock Server or your protected log pipeline