Skip to main content

RBAC

Role-based access control in QRY operates at four nested levels. A user (or group) can be granted access at any level, and the grant cascades downward. The four levels:

Datasource → Catalog → Schema → Table

For SAP HANA, an extra Module level sits between schema and table — see SAP module integration.

How grants compose​

  • A grant at datasource level gives access to every catalog / schema / table inside that datasource.
  • A grant at schema level gives access only to tables in that schema.
  • A grant at table level is per-table.

Effective access for a user is the union of:

  1. Direct grants on the user.
  2. Grants on every group the user is a member of.
  3. Inherited grants from any of the above at a higher level.

If any of those three paths grants access, the user has access. There's no "deny" — RBAC is purely additive.

Where to configure​

Admin > Access Control > RBAC. The page lists every grant in the tenant. Filter by:

  • User — every grant for one user, including inherited from groups.
  • Group — every grant on a group.
  • Datasource — who has access to a specific datasource.

Granting access​

Per-user grant​

Click + New Grant. Pick:

  • Subject — user or group.
  • Resource — datasource, then optionally drill into catalog / schema / table.
  • Capability — read, query, admin (typical levels; tenants can define more).

Click Save. The user (or every group member) sees the resource on their next page load.

Group grant​

Same flow, with a group as the subject. All current and future group members inherit the grant.

Common patterns​

Tenant-wide read access to one datasource​

Grant read + query on the datasource to a "all-employees" group with everyone in it.

Department-segregated data​

Two datasources (sales DB, finance DB), two groups (sales, finance), one grant per group on the matching datasource. Cross-department access requires explicit individual grants.

Sensitive table inside a permitted schema​

Granting the schema and then withholding the table does not work: the schema grant cascades to every table under it, and there is no way to subtract one back out. Revoking a permission deletes the grant itself — it does not create a block that overrides a broader grant.

The pattern: don't grant the parent schema if you only want a subset of its tables — grant the specific tables instead. If the user must keep schema-wide access but some rows or columns have to stay hidden, that's a job for ABAC row-level policies (see ABAC).

External consultant with limited time​

Create a user, add to a group with the right grants, set an expiry on the user account. The user disappears from the tenant when the expiry passes.

Effective permissions​

For any user, Admin > Users > {user} > Effective permissions shows every grant that applies to them, with the path (direct vs. group, and which group). Use this as the source of truth when debugging "why can / can't this user see X?".

Performance​

RBAC is checked at every query — get_secure_service() enforces it on every run_query() call. The check is cached briefly per request, but for batch / concurrent operations use use_cache=False to avoid shared state — see the Security Architecture reference.

The PermissionEngine and SecureQueryProxy are the centralised enforcement points. Always use get_secure_service() for user-initiated SQL; get_service() is for system operations only (migrations, user-less background jobs).

Common issues​

A user can see the datasource in the Catalog but every query fails. RBAC at datasource level alone isn't enough — the user also needs query capability, not just read. Check the grant.

A teammate I added to a group still can't see what other group members see. Group membership cache. Either wait a few seconds or click Refresh effective permissions in the user's profile.

A grant is in place but the user still gets Permission denied. ABAC tag policies or DAC grants on top of RBAC may apply. Check both layers.

Removing a user's group membership left some access in place. The user has a direct grant on the resource that the group also had. Both grants coexist; removing one doesn't remove the other.

Two groups with conflicting capabilities (one grants read, another grants admin). Highest capability wins (additive composition). The user has admin.

See also​

QRYA product of IXEN.