RBAC read-deny: precise per-endpoint permission (extract mapping) + allow counterparts

[esraagamal6]

Follow-up to the read-side RBAC deny-test vertical slice (#359). The slice is generic (zero-grant user → deny). This adds precise per-endpoint RBAC: name the exact permission that gates each read endpoint and assert both directions.

Scope:

• Extract the read endpoint→permission mapping from camunda/camunda service/.../authorization/Authorizations.java (read-side constants like PROCESS_INSTANCE_READ_AUTHORIZATION are declarative/machine-extractable) into a config, e.g. configs/camunda-oca/read-permissions.json, and attach requiredPermission to OperationModel via the spec/registry loader.
• Deny test: grant the probe user everything except the target permission → assert deny (proves that permission gates the endpoint).
• Allow counterpart: grant the probe user exactly the target permission → assert 200.

Why after the slice: the camunda/camunda extraction is its own focused change and the generic slice already establishes the scoped-user + authz-run-mode infra.

Relates to #359. The write-side analog is blocked on upstream camunda/camunda#54727.

[jwulf]

Yes — this generator output is exactly the deterministic runtime oracle that proves the spec's permission claims, and the write-side blocker is now lifted.

camunda/camunda#54727 is being delivered as PR camunda/camunda#54880. It adds an x-required-permissions OpenAPI vendor extension on all 193 v2 operations — reads and writes. So the write-side binding this issue was holding for now exists at the source (declared on the operation, Spectral-guarded, with a drift test against the AuthorizationResourceType enum) — no brittle processor scraper. It also covers reads, so the generator can consume one machine-readable source (x-required-permissions) instead of Authorizations.java (reads) + nothing (writes).

Shape the consumer must handle (the entry array is AND-ed):

• { resourceType, permissionType } — static. allow = grant exactly this → 200; deny = grant all-but-this → denied.
• { anyOf: [ ... ] } — OR group. deny only when none of the alternatives is granted.
• { dynamic: true, note } — permission resolved from the request payload/path at runtime (e.g. deleteResource, broadcastSignal, evaluateExpression's conditional READ_PROCESS_INSTANCE). Not provisionable purely statically — needs the concrete resource constructed, or skip using the note as rationale.
• [] — explicitly public; no deny test.

Important caveat — deny ≠ 403 for authorize-by-filtering endpoints. You already hit this on the read side (search-authorization-api.spec.ts: scoped user → 200 + 0 items). The write-side analog is activateJobs: a caller without PROCESS_DEFINITION:UPDATE_PROCESS_INSTANCE gets an empty job batch (200), not 403, because JobBatchCollector filters to the jobs the caller may update. A naive "assert 403 on deny" will false-pass here.

We're considering adding a reject-vs-filter marker to x-required-permissions so the generator knows whether to assert 403 or 200 + filtered/empty. Would that marker help, or do you already classify endpoints this way?

Net: the allow+deny pair proves the declared permission is necessary (deny) and sufficient (allow) — turning the spec annotation into a tested contract and making the mapping deterministic rather than reviewed (see ADR docs/adr/security/001-endpoint-required-permission-mapping.md, decision D8).

[jwulf]

Follow-up to the note above: the x-permission-enforcement marker is now implemented in camunda/camunda#54880 so the runtime auth test can assert the correct deny shape per endpoint.

Per operation, alongside x-required-permissions:

• reject (default when the marker is absent) → assert a 4xx with no data (403 for writes; 404 for single-resource point reads, where unauthorized is indistinguishable from missing).
• filter → assert 200 with the target resource absent / an empty/scoped result set (authorization is pushed into the search query as a filter).

filter is set on the search-client-filtered reads: top-level search* collection queries, membership/relation search*For{Group,Role,Tenant} queries, the *Statistics/usage-metrics aggregates, and activateJobs. Note not every search* is filter — sub-resource searches that gate on a parent getByKey (e.g. searchProcessInstanceIncidents, searchUserTaskVariables, searchUserTaskAuditLogs) reject with the parent's 404, so read x-permission-enforcement rather than keying off the operationId prefix.

The marker is a reviewed claim, not a proven fact (see ADR D8/D9): unverified endpoints default to reject, so this generator is the deterministic oracle — a misclassification will surface as a test failure (wrong deny shape) rather than a silent pass.