BI Tool Permissions with Semantic Layers: Access Control Guide

Managing permissions across BI tools and semantic layers requires coordinated architecture. When done well, users get appropriate data access regardless of which tool they use, and administrators manage security centrally. Poor coordination creates security gaps, user confusion, and administrative overhead.

This guide covers permission strategies for BI-semantic layer integration, including approaches supported by Codd AI.

Permission Fundamentals

The Permission Challenge

Without coordination, permissions fragment:

Fragmented State:
├── Tableau: Own permission model
├── Power BI: Own permission model
├── Looker: Own permission model
└── Semantic Layer: Own permission model

Result: Users have different access in different tools

The Coordinated Approach

With semantic layer-centered permissions:

Coordinated State:
├── Semantic Layer: Central permission authority
├── Tableau: Inherits from semantic layer
├── Power BI: Inherits from semantic layer
└── Looker: Inherits from semantic layer

Result: Consistent access everywhere

Permission Layers

Layer 1: Object Access

Which data objects can users see?

Level	Example	Where to Enforce
Database	Sales database	Semantic layer
Schema	Regional schemas	Semantic layer
Table/View	Customer data	Semantic layer
Column	Salary field	Semantic layer

Best practice: Enforce at semantic layer. BI tools inherit.

Layer 2: Row-Level Security

Which rows within objects can users see?

Common patterns:

• Geographic: Users see their region only
• Organizational: Users see their department only
• Account-based: Users see their assigned accounts
• Hierarchical: Managers see their team's data

Best practice: Enforce at semantic layer for consistency.

Layer 3: Aggregation Restrictions

What level of detail can users access?

User Type	Allowed Access
Executive	Aggregated summaries
Analyst	Department-level detail
Data Scientist	Transaction-level detail

Best practice: Semantic layer filters or separate objects per access level.

Layer 4: Content Permissions

Which BI content (dashboards, reports) can users access?

Level	Example	Where to Enforce
Dashboard	Executive dashboard	BI tool
Report	Regional report	BI tool
Folder	Department folder	BI tool

Best practice: BI tool manages content access. Semantic layer manages data access.

Architecture Patterns

Pattern 1: Service Account with Pass-Through Identity

BI tool connects with service account, passes user identity for RLS:

User → BI Tool → Service Account Connection → Semantic Layer
                      ↓
              User identity passed
              for row-level security

Configuration:

• Service account has broad data access
• Semantic layer applies RLS based on passed identity
• BI tool configured for identity pass-through

Advantages:

• Simple connection management
• Centralized RLS in semantic layer
• Works with most BI tools

Pattern 2: Per-User Connections

Each user connects with own credentials:

User → BI Tool → User's Credentials → Semantic Layer
                      ↓
              User identity used
              for all access control

Configuration:

• Users authenticate to semantic layer directly
• All permissions based on user identity
• BI tool manages credential storage

Advantages:

• Full audit trail by user
• No service account credential exposure
• Direct identity-to-permission mapping

Pattern 3: Role-Based Service Accounts

Different service accounts for different access levels:

Executive User → BI Tool → executive_service_account → Full Access
Analyst User → BI Tool → analyst_service_account → Limited Access
Viewer User → BI Tool → viewer_service_account → Restricted Access

Configuration:

• Create service accounts per role
• BI tool routes users to appropriate account
• Semantic layer permissions per account

Advantages:

• Simple permission model
• No pass-through complexity
• Clear role separation

Row-Level Security Implementation

Semantic Layer RLS

Configure RLS centrally in the semantic layer:

-- Example RLS policy
CREATE POLICY region_access ON sales_data
FOR SELECT
USING (region = current_user_attribute('region'));

When users query through the semantic layer, they see only authorized rows regardless of BI tool.

User Attributes

Define user attributes for RLS:

Attribute	Use Case	Example
region	Geographic filtering	"North America"
department	Organizational filtering	"Sales"
manager_id	Hierarchical filtering	12345
account_ids	Account-based filtering	[1,2,3]

Populate attributes from identity provider or manual assignment.

RLS Testing

Validate RLS works correctly:

-- Test as specific user
SET ROLE test_user;

SELECT COUNT(*) FROM sales_data;
-- Should return filtered count

SELECT DISTINCT region FROM sales_data;
-- Should return only authorized regions

Test through BI tools as well, not just SQL.

BI Tool Permission Configuration

Tableau

Configure Tableau to respect semantic layer permissions:

Published Data Sources:

• Connect to semantic layer with appropriate account
• Configure user filter pass-through if needed
• Set data source permissions separate from workbook

Server Permissions:

• Projects for content organization
• Groups for permission management
• Site roles for capability levels

Integration:

User → Tableau Server → Published Data Source → Semantic Layer (RLS Applied)

Power BI

Configure Power BI for semantic layer integration:

Workspace Permissions:

• Admin, Member, Contributor, Viewer roles
• Control content access

Dataset Permissions:

• Build permission for report creation
• Read permission for consuming

Row-Level Security:

• Can be in Power BI or semantic layer
• Semantic layer preferred for cross-tool consistency

Integration:

User → Power BI Service → Dataset → DirectQuery → Semantic Layer (RLS Applied)

Looker

Configure Looker permissions:

Access Grants:

access_grant: region_access {
  user_attribute: region
  allowed_values: ["North America", "Europe", "Asia"]
}

Model Permissions:

• Control which models users access
• Map to semantic layer objects

Explore Permissions:

• Control explore access
• Limit fields visible

Integration:

User → Looker → Access Grants Applied → Semantic Layer (Additional RLS)

Synchronizing Permissions

Identity Provider Integration

Connect semantic layer to organizational identity:

Identity Provider (Okta, Azure AD, etc.)
         ↓
    User Attributes (region, department, role)
         ↓
    Semantic Layer (receives attributes)
         ↓
    RLS Applied Based on Attributes

Group-Based Permissions

Manage permissions via groups:

Group	Semantic Layer Access	BI Tool Access
Sales Team	Sales data, own region	Sales dashboards
Finance Team	All financial data	Finance dashboards
Executives	All data, aggregated	Executive dashboards

Maintain groups in identity provider, sync to semantic layer and BI tools.

Permission Audit

Regularly audit permission alignment:

Audit Checklist:
□ Semantic layer permissions match policy
□ BI tool permissions align with semantic layer
□ RLS tests pass for sample users
□ No unintended access gaps or overlaps
□ Terminated users removed from all systems

Common Challenges

Challenge: Permission Drift

Over time, permissions diverge between systems.

Solution:

• Regular audit schedule
• Automated permission sync
• Single source of truth for roles
• Documentation of intended state

Challenge: Over-Permissioned Service Accounts

Service accounts accumulate excessive access.

Solution:

• Apply least-privilege principle
• Use role-based service accounts
• Implement identity pass-through
• Regular service account review

Challenge: RLS Performance

Row-level security slows queries.

Solution:

• Optimize RLS filter queries
• Partition data by common RLS dimensions
• Cache filtered results where appropriate
• Test RLS performance under load

Challenge: Cross-Tool Inconsistency

Users see different data in different tools.

Solution:

• Centralize RLS in semantic layer
• Audit cross-tool access
• Standardize permission model
• Test same queries across tools

Codd AI Integration

Codd AI provides centralized permission management:

• Built-in row-level security
• Identity provider integration
• Consistent enforcement across BI tools
• Audit logging for compliance

Organizations can manage permissions once and enforce everywhere.

Best Practices Summary

1. Centralize data permissions in the semantic layer
2. Use BI tools for content permissions (dashboards, reports)
3. Implement RLS at semantic layer for cross-tool consistency
4. Integrate with identity provider for user attributes
5. Use service accounts carefully with least privilege
6. Pass user identity when RLS requires individual filtering
7. Audit regularly to catch permission drift
8. Test permissions through all BI tools, not just direct queries
9. Document the permission model so administrators understand the design
10. Plan for scale as user counts and data sensitivity grow

Coordinated permissions across BI tools and semantic layers create a secure, consistent analytics environment where users trust they are seeing appropriate data regardless of how they access it.