Roles & access control

StrataBI uses role-based access control (RBAC) to govern who can view, build, and administer dashboards. This page describes the access model and how roles are assigned.

Roles

Access is organized around a small, explicit set of roles:

The set is intentionally small so that permissions are easy to reason about and audit. Roles are additive — each includes the capabilities of the one below it.

Scoping

Because each StrataBI deployment is owned by a single organization and runs in that organization's account, access control is concerned with users within your organization rather than isolation between tenants. Within that boundary, access can be scoped so that roles apply to specific dashboards or to specific data prefixes — letting a team see and build only the dashboards and datasets relevant to them.

Where roles come from

Roles derive from the group or role claims asserted by your identity provider (see Authentication & SSO). Mapping IdP groups to StrataBI roles keeps user lifecycle in one place: granting or revoking access in your directory propagates to StrataBI on the user's next sign-in, with no separate user list to maintain.

Raw HTML permission

raw_html blocks render arbitrary HTML and are an injection surface, so they carry a dedicated permission separate from page and module access. When RBAC is enabled, a raw_html block authored in a regular dashboard renders only for users whose role grants the Raw HTML permission; everyone else sees a "Restricted" placeholder in that tile. Only a governed source is exempt: HTML produced by a module (a lambda exec tile — modules are governed content, already gated by module access). A pinned dashboard (admin-only, curated) is the admin escape hatch. Everything else is rejected, including HTML pulled from the S3 cache (cache exec) — a storage location is not governance, since what matters is who may write there, so cached HTML is treated as untrusted. The workarounds are deliberate: render the HTML through a governed module, pin the dashboard, or grant the permission per role in the admin console's RBAC tab. This keeps untrusted dashboard authors from introducing HTML that runs in other users' sessions, while leaving vetted module output unaffected.

Enforcement

Access control is governed by deployment configuration and enforced by the runtime: the caller's role is evaluated before a dashboard is served or modified, and administrative actions are restricted to the Admin role. Combined with the identity layer, this means every action is attributable to an authenticated user operating within their assigned role.