Skip to content

RBAC read-deny: deploy/runtime get-by-key tier — attach deny-checks to positive-suite chains #378

@esraagamal6

Description

@esraagamal6

Follow-up to #373. The remaining ~15 get-by-key reads are deploy/runtime resources — process/decision definitions, decision-requirements, resources, forms, process-instances, user-tasks, incidents, jobs, variables, element-instances, agent-instances, batch-operations, decision-instances, audit-logs.

To deny-test these meaningfully you need a real existing instance, which for these requires deploying a BPMN/DMN model and/or running a process and waiting for the runtime entity to appear — i.e. the positive suite's deployment/execution machinery. Re-provisioning that inside the rbac global-setup would duplicate it and be slow/flaky.

Proposed approach: rather than re-provision, attach deny-checks onto the positive suite's existing entity chains — where an instance has already been created/emitted, add a step that re-fetches it as the zero-grant probe and asserts 403/404. This reuses the established instance and keeps the rbac setup lean.

Needs design (how the rbac assertion hooks into a positive chain; whether it's a new emitter mode or a chain annotation). Larger than #373.

Relates to #359, #373.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions