Skip to main content

Role-Based Access Control (RBAC)

QRY provides enterprise-grade security with granular, hierarchical permission controls that ensure users only access data they're authorized to see.

Overview​

RBAC in QRY enables administrators to control data access at multiple levels, from entire data sources down to individual tables. Permissions are enforced consistently across all interfaces - chat, API, and administrative tools.

Access Control Hierarchy​

Datasource (Database Connection)
  ↓
Catalog/Database
  ↓
Schema
  ↓
Table

Permissions granted at higher levels automatically cascade down unless overridden at lower levels.

Key Concepts​

Permission Types​

Read Access

  • Query tables and view data
  • See table structures and schemas
  • Execute SELECT queries
  • View query results in conversations

Write Access

  • Modify data (INSERT, UPDATE, DELETE)
  • Create temporary tables
  • Execute data modification queries
  • Note: Typically restricted to specific use cases

Admin Access

  • Manage permissions for the resource
  • Configure connection settings
  • View audit logs
  • Delegate access to other users

Permission Scopes​

User-Level: Permissions granted directly to individual users

  • Highest specificity
  • Overrides group permissions
  • Use for exceptional cases

Group-Level: Permissions granted to user groups

  • Ideal for department or team-based access
  • Users inherit all group permissions
  • Easier to manage at scale

System-Level: Default permissions

  • Fallback when no specific permissions exist
  • Can be restricted by administrators
  • Typically most restrictive

How RBAC Works​

Permission Evaluation​

When a user attempts to access data, QRY evaluates permissions in this order:

  1. User-specific permissions (if any)
  2. Group permissions (all groups user belongs to)
  3. Default permissions (system-wide settings)

Most permissive wins: If any permission grants access, access is allowed.

Example Scenarios​

Scenario 1: Department Access

User: Alice
Groups: Finance Team
Data: sales_database.finance_schema

Evaluation:
- Finance Team has READ access to finance_schema
- Result: Alice can query all tables in finance_schema

Scenario 2: Mixed Permissions

User: Bob
Groups: Engineering, Analytics
Data: production_database.customer_table

Evaluation:
- Engineering has NO access to customer_table
- Analytics has READ access to customer_table
- Result: Bob can query customer_table (most permissive wins)

Scenario 3: Explicit Denial

User: Carol
Direct Permission: DENY on production_database
Groups: Admin Team (full access)

Evaluation:
- Direct user denial takes precedence
- Result: Carol cannot access production_database despite group permissions

User Groups​

Creating and Managing Groups​

Groups simplify permission management for teams and departments:

Common Group Structures:

  • Department-Based: Finance, Marketing, Engineering, Sales
  • Role-Based: Analysts, Managers, Executives, Admins
  • Project-Based: Project Apollo, Q4 Initiative, Migration Team

Group Management (Admin Interface):

  1. Navigate to Admin → User Groups
  2. Click "Create Group"
  3. Name the group and add description
  4. Add users to the group
  5. Assign permissions to group

Group Inheritance​

Users can belong to multiple groups and inherit all permissions:

User: David
Groups:
  - Data Team (access to analytics databases)
  - Marketing (access to marketing databases)
  - Contractors (restricted to read-only)

Effective Permissions:
  - READ: All analytics + marketing databases
  - WRITE: None (most restrictive contractor rule applies)

Permission Management​

Granting Permissions​

Via Admin Interface:

  1. Navigate to Admin → Permissions
  2. Select resource level (Datasource/Catalog/Schema/Table)
  3. Choose user or group
  4. Select permission type (Read/Write/Admin)
  5. Click "Grant Access"

Bulk Operations:

  • Grant permissions to multiple users/groups at once
  • Apply template permissions across similar resources
  • Import permissions from CSV

Permission Templates​

Common permission patterns for quick setup:

Analyst Template

- READ: All production databases
- READ: All analytics schemas
- NO WRITE ACCESS

Admin Template

- ADMIN: All datasources
- READ/WRITE: Configuration tables
- FULL ACCESS: User management

Executive Template

- READ: Summary and aggregated data only
- NO ACCESS: Detailed transaction data
- READ: Dashboard and report tables

Practical Use Cases​

Multi-Tenant SaaS​

Requirement: Each customer sees only their data

Solution:

Group: Customer_A
Permissions: READ on database.customer_a_schema

Group: Customer_B
Permissions: READ on database.customer_b_schema

Enforcement: Users only query tables they have access to

Departmental Data Isolation​

Requirement: Finance sees financial data, Sales sees CRM data

Solution:

Group: Finance Team
- READ: erp_database.finance_schema
- READ: erp_database.accounting_schema
- DENY: crm_database.*

Group: Sales Team
- READ: crm_database.*
- READ: erp_database.products
- DENY: erp_database.finance_schema

Compliance Requirements​

Requirement: PII access must be logged and restricted

Solution:

Table: customers_pii
- DENY: Default (all users)
- READ: Compliance_Team (with audit logging)
- ADMIN: Privacy_Officer

Audit Settings:
- Log all queries to customers_pii
- Require justification for access
- Alert on unusual access patterns

Security Features​

Automatic Enforcement​

Query-Time Validation

  • Every query checked against user permissions
  • Unauthorized tables automatically filtered out
  • Schema explorer shows only accessible objects

Conversation-Level Security

  • AI only suggests queries for authorized data
  • Chat history filtered by access rights
  • Shared conversations respect recipient permissions

Audit Logging​

Track all permission-related activities:

Logged Events:

  • Permission grants and revocations
  • Access attempts (successful and denied)
  • Permission changes
  • Group membership modifications

Audit Log Access:

Admin → Audit Logs → RBAC Events

Filters:
- User
- Resource
- Action (granted, denied, modified)
- Date range

Dynamic Permission Updates​

Permissions take effect immediately:

  • No system restart required
  • Active sessions respect new permissions
  • Cached queries invalidated on permission change

Admin Best Practices​

Least Privilege Principle​

Grant only the minimum access required:

  1. Start Restrictive: Begin with no access, grant as needed
  2. Use Groups: Avoid individual user permissions when possible
  3. Regular Audits: Review permissions quarterly
  4. Remove Unused: Revoke access when users change roles

Group Organization​

Effective group structures:

DO:

  • Use descriptive group names (e.g., "Finance_Analysts")
  • Document group purposes
  • Limit group count (5-20 groups for most organizations)
  • Nest permissions logically

DON'T:

  • Create user-specific groups
  • Overlap group responsibilities
  • Grant excessive permissions "just in case"
  • Ignore group cleanup

Permission Documentation​

Maintain clear documentation:

Group: Marketing_Team
Purpose: Access marketing campaign data
Members: 15 users
Permissions:
  - READ: marketing_db.campaigns
  - READ: marketing_db.leads
  - READ: crm_db.contacts
Restrictions:
  - NO ACCESS to PII fields
  - NO WRITE permissions
Last Reviewed: 2025-10-01

Troubleshooting​

Common Issues​

User Can't See Database

  1. Check datasource-level permissions
  2. Verify group membership
  3. Check for explicit DENY rules
  4. Confirm database connection is active

Unexpected Access Denial

  1. Review audit log for specific denial reason
  2. Check most restrictive permission in effect
  3. Verify resource names match exactly
  4. Confirm user hasn't been removed from groups

Permissions Not Taking Effect

  1. Verify admin privileges for granting permissions
  2. Check permission was saved successfully
  3. Clear user session cache
  4. Verify correct resource hierarchy

RBAC + ABAC: Complete Access Control​

RBAC controls which tables users can access. For even finer control over which rows within those tables, use ABAC (Attribute-Based Access Control).

How They Work Together​

RBAC (Table-Level): "Alice can access the sales database" ABAC (Row-Level): "Alice can only see sales where region = 'EMEA'"

Example: Multi-Region Sales Team​

Setup:

RBAC Configuration:

Group: Sales Team
Permission: READ access to sales_database
Result: All sales team members can query sales tables

ABAC Configuration:

Policy: Regional Sales Restriction
Target: Sales Team (group)
Tables: Any table tagged with "has_region"
Required Filter: region = user.assigned_region
Result: Each sales person sees only their region's data

Combined Effect:

  • RBAC grants base access to the sales database
  • ABAC automatically filters queries to show only relevant rows
  • Two-layer security ensures comprehensive protection

When to Use ABAC​

Consider ABAC when you need:

✅ Row-level filtering (not table-level blocking) ✅ Multi-tenant data (customers, subsidiaries, regions) ✅ Compliance requirements (data residency, PII restrictions) ✅ Scalable access patterns (same tables, different row subsets)

Learn More: ABAC Feature Guide

API Access​

Manage permissions programmatically:

# Grant permission
POST /api/permissions
{
  "resource_type": "schema",
  "resource_id": "production_db.sales_schema",
  "principal_type": "group",
  "principal_id": "analytics_team",
  "permission": "read"
}

# Check user permissions
GET /api/permissions/user/{user_id}/resources

# Audit log
GET /api/audit/permissions?user_id={id}&start_date={date}

FAQ​

Q: Can users see tables they don't have access to? A: No, the schema explorer only shows resources the user can access.

Q: What happens to shared conversations if permissions change? A: Recipients can only view parts of the conversation they have access to.

Q: Can I temporarily grant access? A: Yes, use time-limited group membership or temporary permissions (enterprise feature).

Q: How do I know who has access to sensitive data? A: Use Admin → Permissions → Resource Permissions to see all users/groups with access.

Q: Can permissions be automated? A: Yes, use the API or integrate with your IDP for automated provisioning.

Next Steps​

  • Read the Admin Guide for detailed permission management workflows
  • Learn about ABAC for row-level security within tables
  • Explore Database Connectivity to set up datasource connections
  • Explore Workspaces for team collaboration and shared context
  • See QRY Nexus for Data Products with consumer access grants, row filters, and column masking

RBAC ensures that the right people have access to the right data at the right time - nothing more, nothing less.

QRYA product of IXEN.