Access Control (RBAC)
Enterprise feature
Role-Based Access Control is available in gdotv Enterprise. In other editions of gdotv, every signed-in user has full access to the workspace. If you'd like to discuss upgrading to gdotv Enterprise, contact us at sales@gdotv.com.
gdotv Enterprise lets you control what each member of your team can see and do, per database connection. Access control is built on your Keycloak realm: users, groups and roles are standard Keycloak objects, and gdotv maps them onto three well-defined access levels — so it works with your existing identity setup, including any identity provider (SSO, LDAP, etc.) you have federated into Keycloak.
The three roles
| Role | Intended for | Summary |
|---|---|---|
| Business | Analysts and business users | Read-only: browse data, view schemas, use the Graph Data Explorer, and run queries and dashboards that were saved and shared by others. Cannot write ad-hoc queries or modify anything. |
| Developer | Engineers and data practitioners | Everything Business can do, plus: write and run ad-hoc queries, create and edit queries/folders/dashboards, manage data and stylesheets, import/export, use the AI Query Assistant, view query logs, and create new connections. |
| Admin | Platform owners | Everything Developer can do, plus: manage application, AI provider and RDF settings, manage role-to-connection access bindings, and administer Keycloak roles, users and groups from inside gdotv. |
How access is evaluated
A user's access is determined by two things:
- A global role, derived from the Keycloak realm roles on their account. By default the realm roles
gdotv-admin,gdotv-developerandgdotv-businessmap to the Admin, Developer and Business levels respectively. The global role applies across all connections. - Per-connection grants (called bindings): a binding grants everyone holding a given Keycloak role a chosen access level on one specific connection.
The effective access level on a connection is the most permissive of the user's global role and any bindings that apply to them. Access is additive — a binding only ever grants access on top of a user's global role, it never reduces it. A typical setup gives most users a low (or no) global role and grants access per connection, reserving the global gdotv-developer/gdotv-admin roles for people who should have that level everywhere.
Authorization is enforced in the gdotv backend on every request and fails closed: a user with no recognised role has no access, and unknown operations are denied by default.
What each role can do
Per connection (governed by the effective role on that connection):
| Capability | Business | Developer | Admin |
|---|---|---|---|
| View connection, browse schema, use the Graph Data Explorer | ✓ | ✓ | ✓ |
| Run saved queries and view shared dashboards | ✓ | ✓ | ✓ |
| Write and run ad-hoc queries | ✓ | ✓ | |
| Create and edit queries, folders and dashboards | ✓ | ✓ | |
| Modify data, manage stylesheets, import and export | ✓ | ✓ | |
| Use the AI Query Assistant (text-to-query) | ✓ | ✓ | |
| View query logs and confidential connection values | ✓ | ✓ |
Global operations (governed by the global role only):
| Capability | Business | Developer | Admin |
|---|---|---|---|
| Create new connections | ✓ | ✓ | |
| View application, AI provider and RDF settings | ✓ | ✓ | |
| Change application, AI provider and RDF settings | ✓ | ||
| Manage access bindings (the Access Control screen) | ✓ | ||
| Manage Keycloak roles, users and groups from gdotv | ✓ |
Read-only means read-only
Business users can run saved queries — but gdotv does not simply trust that a saved query is harmless. Every query execution is analyzed, and a query requires write access not only when it demonstrably mutates data, but whenever gdotv cannot prove that it doesn't. Queries that fail to parse, arbitrary console-mode scripts, and procedure or service calls (whose effects can't be determined from the query text) are all treated as writes and blocked for Business users. This deliberately strict, fail-closed policy means a read-only role can be handed to business stakeholders with confidence.
Managing access
Open Settings → Access Control (visible to Admins only). The screen has four tabs:
- Connection Access — the bindings list: grant a Keycloak role a Business, Developer or Admin level on a specific connection, and review or remove existing grants. You can also jump here scoped to one connection from that connection's actions menu.
- Roles, Users and Groups — manage the Keycloak realm objects those bindings rely on without leaving gdotv: create roles, search users and assign their roles, and organise users into groups.
The Roles/Users/Groups tabs use gdotv's Keycloak admin integration. If it isn't configured in your deployment, manage roles, users and groups in the Keycloak admin console directly — bindings to existing role names still work from the Connection Access tab.
Auditing
Administrative changes made through Keycloak (users created, roles granted, and so on) are recorded in Keycloak's admin event log, and logins are recorded in its user event log — both are enabled by default in the realms gdotv ships and are visible in the Keycloak admin console under Realm settings → Events.
Customising role names
If your realm already has its own naming convention, the realm-role names gdotv maps to each level are configurable via application properties:
| Property | Default |
|---|---|
gdotv.authz.role.admin | gdotv-admin |
gdotv.authz.role.developer | gdotv-developer |
gdotv.authz.role.business | gdotv-business |