Authorization Model

Datafi's authorization model combines Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) with query-level security to enforce fine-grained access at every level of the platform. Each layer addresses a different dimension of the access decision.

Multi-Level Authorization Flow

Every request passes through three authorization layers in sequence. A failure at any layer terminates the request immediately.

Role-Based Access Control (RBAC)

RBAC governs access based on the user's assigned role. Roles define broad permission boundaries for platform resources.

Built-in Roles

Role	Datasets	Agents	Connections	Admin
Viewer	Read	Run	View	None
Editor	Read, Write	Run, Create, Edit	View, Create	None
Admin	Full	Full	Full	Full
Super Admin	Full	Full	Full	Full + Tenant Mgmt

Role Assignment

Roles are assigned at two scopes:

• Tenant scope -- the role applies to all resources within the tenant.
• Workspace scope -- the role applies only to resources within a specific workspace.

# Example role assignment
user: [email protected]
assignments:
  - scope: tenant
    role: viewer
  - scope: workspace:analytics
    role: editor

In this configuration, Jane has Viewer access across the tenant but Editor access within the analytics workspace. The most permissive matching role applies for a given resource.

Attribute-Based Access Control (ABAC)

ABAC evaluates contextual attributes to make fine-grained decisions that RBAC alone cannot express. While RBAC answers "does this role allow this action?", ABAC answers "do the current conditions allow this specific request?"

Attribute Categories

Category	Examples	Evaluated Against
User attributes	Department, clearance level, location	User profile and IdP claims
Resource attributes	Data classification, sensitivity tags, owner	Resource metadata
Action attributes	Read, Write, Delete, Run	Requested operation
Environment attributes	Time of day, IP address, device posture	Request context

ABAC Policy Example

{
  "name": "restrict-pii-to-compliance-team",
  "description": "Only compliance team members can access PII-tagged datasets",
  "condition": {
    "all": [
      { "resource.tags": { "contains": "pii:high" } },
      { "user.department": { "eq": "compliance" } }
    ]
  },
  "action": "Read",
  "effect": "Allow"
}

This policy ensures that only users in the compliance department can read datasets tagged as pii:high, regardless of their RBAC role.

Combining RBAC and ABAC

RBAC and ABAC are not mutually exclusive -- they work together.

Even though the Editor role permits reading datasets, ABAC can further restrict access based on the specific dataset's tags and the user's attributes.

Query-Level Security

After RBAC and ABAC authorize the user to access a resource, query-level security validates the specific SQL operations the user is attempting.

This layer performs:

1. SQL parsing -- the query is decomposed into an abstract syntax tree.
2. Table extraction -- all referenced tables are identified.
3. Column extraction -- all referenced columns are identified, including those in WHERE, JOIN, and ORDER BY clauses.
4. Permission validation -- each table and column is checked against the user's column-level policies.

// Example permission check (internal representation)
message QueryPermissionCheck {
  string user_id = 1;
  repeated string tables = 2;    // ["customers", "orders"]
  repeated string columns = 3;   // ["customers.name", "orders.total"]
  string action = 4;             // "Read"
}

info

Query-level security is particularly important for AI agents, which generate SQL dynamically. Every agent-generated query is validated against the invoking user's permissions before execution.

Authorization Decision Pipeline

The complete authorization pipeline for a single request:

Deny Precedence

Across all authorization layers, Deny always takes precedence over Allow.

Scenario	RBAC	ABAC	Query Security	Result
All layers allow	Allow	Allow	Allow	Allowed
RBAC denies	Deny	--	--	Denied
ABAC denies	Allow	Deny	--	Denied
Query security denies	Allow	Allow	Deny	Denied
No matching policy	--	--	--	Denied (default)

Best Practices

1. Use RBAC for broad access boundaries. Define roles that map to job functions and assign them at the appropriate scope.
2. Use ABAC for contextual refinement. Layer ABAC policies on top of RBAC to handle exceptions and sensitive data classifications.
3. Define column-level policies for sensitive fields. Do not rely on table-level access alone when individual columns contain PII or financial data.
4. Audit the authorization pipeline. Review denied requests regularly to identify misconfigured policies or unauthorized access attempts.
5. Apply the principle of least privilege. Grant the minimum set of roles and attributes needed for each user's responsibilities.