Skip to main content

Trust Model

⚠ Operators: read this before enabling Query Studio (especially Expert mode) on any deployment.

Scope of the MVP​

Query Studio's MVP is designed for single-trust-boundary deployments:

  • One customer / one seller scope per Meveo instance, or
  • Trusted internal users only.

It does not include:

  • Field-Level Security (column masking by role)
  • Row-Level Security by seller / country / business-unit
  • Multi-tenant query isolation beyond the existing JPA provider discriminator

Tenant isolation via provider does still apply — users in tenant A cannot see rows in tenant B. But within a tenant, every user with queryUser can see every row of the entities they query, regardless of seller, country, or business-unit ownership of those rows.

What Quick and Deep modes inherit​

Both Quick Query (/api/rest/v2/generic/all/{entity}) and Deep Query (/api/rest/query?...) flow through the JPA layer, so they inherit Opencell's existing SecuredBusinessEntity row-level security if and only if the deployment has it enabled (secured.entities.enabled=true) and configured. This is partial RLS — useful for some deployments, but not a full FLS / per-seller story.

What Expert mode does NOT inherit​

Expert Query bypasses SecuredBusinessEntity entirely. It runs a native SQL statement directly against the database via EntityManager.createNativeQuery(...). There is no row-level filtering. There is no field-level masking. The only protections are:

  • Tokenised validator: the SQL must start with SELECT / WITH / EXPLAIN; DDL, DML, system catalogs, comment markers, and ; are rejected.
  • Read-only transaction at the JDBC level.
  • Hard LIMIT and statement-timeout enforced by the governor (default 1 000 rows / 30 s sync / 600 s async).
  • Audit log on every submission and result.

Expert mode is gated by the queryExpert Keycloak role. Only grant this role to users you would trust with read access to the entire database.

Enable / disable checklist for operators​

Before granting any user queryExpert on a deployment that serves more than one customer / seller / country:

  • Confirm with stakeholders that Expert users are trusted with full read access to the database (across all tenants the node serves).
  • Verify provider discriminator filtering is correctly applied at the persistence layer (i.e. the deployment is not a "shared schema, shared data" topology).
  • Configure the governor knobs to suit the cluster size — see Governor limits. Tighten the per-user concurrency caps; Expert-specific cluster-wide caps are V2 backlog and not enforced today.
  • Ensure audit log persistence is wired and monitored — every Expert submission and result is logged.
  • Document the policy: who has queryExpert, why, for how long, and what the review cadence is.

V2 plans​

The following are first-class V2 items — see the implementation plan for the full list:

  • Field-Level Security (column masking) with per-role visibility, query rewrite at the JPA / Hibernate interceptor layer, UI-level field hiding consistent with the backend.
  • Row-Level Security by seller / country / business-unit — automatic predicate injection for Quick + Deep + Expert.
  • Per-tenant FLS / RLS configuration UI.
  • Cross-seller audit reports (queries that touched data outside the user's seller scope).

Until those land, do not enable Expert mode on a multi-tenant cluster where users must be restricted to a subset of data. If you do, you do so at your own risk; the documentation, in-app help drawer, and red banner inside the Expert tab all surface this warning.