Cedar

policiesResource and schemaResource are required classpath: or file: resource URIs containing Cedar policy text and Cedar schema text. entitiesResource optionally supplies static Cedar entity JSON through the same local resource schemes. Remote resource schemes are rejected; this preview does not manage HTTP resource-fetch deadlines. principal, action and resource are required configured Expression references returning an SDK EntityUID or a canonical UID string, for example Action::"read". An optional context expression explicitly selects a POJO or map; nothing implicitly reads the body or forwards headers. Expression references use normal registry binding, for example principal=#bean:workloadPrincipal. Policy selection and input expressions are fixed by configuration; there are no dispatch headers.

Camel components are configured on two separate levels:

The Cedar component supports the following options which are listed below.

The Cedar endpoint is configured using URI syntax:

With the following path and query parameters:

The producer records an immutable CedarAuthorizationResult in the CamelCedarAuthorizationResult exchange property. The body, including stream bodies, remains unchanged unless an explicitly configured expression or provider consumes it. Every evaluation clears the previous result property and a same-named inbound header.

Cedar has default deny and forbid precedence. Its native semantics skip erroneous policies, so an erroneous forbid and a matching permit can produce a raw allow. The default strict=true returns effective ERROR whenever evaluation diagnostics are present, including that case. Explicit strict=false honors the raw decision and retains diagnostics; use it only when native skip-on-error semantics are intended. Request/schema/entity failures and engine failures remain ERROR in both modes. There is no failOpen option.

The producer returns structured results for callers to inspect; it does not enforce access itself. CedarSecurityPolicy uses the same evaluator and throws CamelAuthorizationException on effective deny or error, preventing the guarded processor from running. Its denial message contains the effective outcome, and the result remains available to error handling. It sets Exchange.AUTHENTICATION_FAILURE_POLICY_ID to CedarSecurityPolicy on rejection and clears that header before the next check. Result toString() omits input and diagnostic contents. An evaluation failure of one exchange is logged at WARN with the exception class, or with the evaluator’s own reason when it rejected the input (an expression that did not yield an entity UID, a null or oversized context, invalid provider entity data); the SDK’s message is never logged. Do not use principal/resource values as metric labels or log an entire exchange to diagnose a decision.

Startup loads bounded resources, parses policy and schema, validates their compatibility, and validates static entities. Every authorization enables SDK request validation; the entities a provider adds are validated against the same schema for that request, while the static entities were validated when the snapshot was loaded. maxResourceSize defaults to 1 MiB per resource, explicit context JSON, and provider entity JSON. Resources close after loading; a Rust toolchain and a remote authorization service are not required.

An endpoint’s reload() explicitly loads and validates a complete candidate before publishing it atomically. A failed reload throws a sanitized exception and keeps the previous revision active. Its message, also logged at WARN, names the step (reading, parsing or validating), the option (policiesResource, schemaResource or entitiesResource), the exception class and, for a failed policy validation, the policy identifiers and error kinds; the SDK message, which can contain policy text or entity attributes, is neither logged nor kept as the cause. A failed first start says that no revision is active. Concurrent exchanges use a single old or new immutable snapshot, never partially mutated policy/schema/entity collections. No SDK PolicySet or mutable entity collection is exposed. There is no filesystem watcher or per-message resource reload.

CedarSecurityPolicy.reload() reloads its active evaluator. One policy bean can guard several route segments in the same CamelContext; the last segment stopping releases the evaluator. Use separate policy beans for separate CamelContexts. Stopping and starting an endpoint or policy reloads resources and rechecks native availability. JNI loading is JVM-scoped and the SDK has no per-engine native close operation.

An optional CedarEntityProvider returns request-scoped Cedar entity JSON:

The provider owns its I/O deadlines, cache freshness and authorization-data provenance. Provider entities are combined with static entities for this request; duplicate UIDs are rejected. Malformed or schema-invalid provider data produces ERROR. No exchange, provider data or credential is retained in the result.

Authenticate the transport first. A SpiffeSecurityPolicy on a consumer configured for verified mutual TLS records CamelSpiffePeerId as an exchange property. These examples enter direct:verifiedWorkload only from that authenticated route segment:

spiffeSsl and spiffePolicy must be configured as described in SPIFFE mutual TLS. An untrusted message header is not a verified identity. Do not route unauthenticated callers directly to the internal entry point or copy caller headers into the identity property.

The supplied CedarEntityUidExpression constructs UID values as data from a configured entity type and exactly one constant id or exchangeProperty. It safely handles quotes in identifiers; never concatenate an external identifier into policy text.

Use these files on the classpath:

This preview uses Cedar Java 4.11.0’s uber classifier, including its native library. Execution is tested on Linux amd64 with glibc and Java 21. The artifact also packages Linux arm64 GNU/glibc, macOS amd64/arm64, and Windows amd64 libraries; packaging inspection is not runtime validation of those targets. Stock musl Linux, ppc64le and s390x have no matching bundled library. GraalVM native image is not validated or advertised by this component.

Native extraction needs an appropriate writable, executable location. Use a tested glibc JVM image and verify startup in your deployment image; a read-only or noexec temporary filesystem requires an explicit native-loading configuration following the Cedar Java and JNE documentation. Startup errors name the exception class, the operating system and the architecture when the native library cannot be initialized, and the engine version when the SDK JAR declares one. Cedar uses Jackson 2 in its normal packages; it does not use Camel’s Jackson 3 serializer. The first implementation does not modify the SDK’s JVM-global native cache settings.