Home > Docs > Best Practices > Identity & RBAC Patterns

🔑 Identity & RBAC Patterns for Microsoft Fabric¶

Last Updated: 2026-04-13 | Version: 1.0.0

📑 Table of Contents¶

• 🎯 Overview
• 🏗️ Architecture
• 👥 Workspace Roles
• 📦 Item-Level Permissions
• 🔒 Data Security
• 🤖 Service Identity
• 🎰 Casino RBAC Model
• 🏛️ Federal RBAC Model
• 🔄 Lifecycle & Governance
• ⚠️ Common Pitfalls
• 📚 References

🎯 Overview¶

Identity and Role-Based Access Control (RBAC) in Microsoft Fabric spans five layers: Entra ID (Azure AD) for authentication, workspace roles for broad collaboration, item-level permissions for fine-grained artifact control, data security (RLS, CLS, OLS) for row/column/object filtering, and audit logging for accountability. A well-designed RBAC strategy ensures the principle of least privilege at every layer while supporting the operational needs of casino gaming compliance officers, federal data stewards, and analytics teams.

Why Multi-Layered RBAC?¶

Guiding Principles¶

1. Least privilege — Grant the minimum permissions required for each role
2. Role-based, not user-based — Assign permissions to Entra ID security groups, never individual users
3. Defense in depth — Layer workspace roles, item permissions, and data security together
4. Automation — Use Managed Identities and Service Principals for non-interactive workloads
5. Auditability — Every permission change and data access event must be logged

Key Insight: Fabric workspace roles control platform actions (create, edit, delete items). Data security (RLS/CLS/OLS) controls data visibility. Both are required — a user with Viewer workspace role still sees all data unless RLS filters are applied.

🏗️ Architecture¶

End-to-End Identity & Access Flow¶

flowchart TB
    subgraph EntraID["Entra ID (Azure AD)"]
        style EntraID fill:#6C3483,color:#fff
        U1[Users & Groups]
        SP[Service Principals]
        MI[Managed Identities]
        CAP[Conditional Access Policies]
    end

    subgraph FabricTenant["Microsoft Fabric Tenant"]
        style FabricTenant fill:#2471A3,color:#fff
        subgraph WS["Workspace Roles"]
            WR1[Admin]
            WR2[Member]
            WR3[Contributor]
            WR4[Viewer]
        end
        subgraph Items["Item Permissions"]
            IP1[Lakehouse Read/Write]
            IP2[Report Read/Share]
            IP3[Notebook Execute]
            IP4[Warehouse Connect]
        end
        subgraph DataSec["Data Security"]
            RLS[Row-Level Security]
            CLS[Column-Level Security]
            OLS[Object-Level Security]
        end
    end

    subgraph Audit["Audit & Compliance"]
        style Audit fill:#27AE60,color:#fff
        AL1[Unified Audit Log]
        AL2[Admin Monitoring]
        AL3[Purview Data Map]
    end

    U1 -->|Authenticates via| CAP
    SP -->|Service-to-service| CAP
    MI -->|Passwordless| CAP
    CAP -->|Authorized| WS
    WS -->|Scoped to| Items
    Items -->|Filtered by| DataSec
    DataSec -->|Logged in| Audit

Identity Resolution Flow¶

sequenceDiagram
    participant User as 👤 User / Service
    participant Entra as Entra ID
    participant Fabric as Fabric Service
    participant WS as Workspace
    participant Data as Data Layer

    User->>Entra: Authenticate (MFA/PIV/CAC)
    Entra-->>User: Access Token (claims: UPN, groups, roles)
    User->>Fabric: Request resource (token)
    Fabric->>Fabric: Validate token + Conditional Access
    Fabric->>WS: Check workspace role membership
    WS-->>Fabric: Role: Viewer/Contributor/Member/Admin
    Fabric->>Data: Apply item permissions
    Data->>Data: Apply RLS/CLS/OLS filters
    Data-->>User: Filtered data response
    Fabric->>Fabric: Write audit log entry

👥 Workspace Roles¶

Role Capability Matrix¶

Fabric provides four workspace roles with cumulative permissions. Each role inherits all capabilities of the roles below it.

Least-Privilege Persona Mapping¶

Map organizational personas to the minimum workspace role required:

Entra ID Security Group Strategy¶

Always assign workspace roles to security groups, not individual users:

# Naming convention: sg-fabric-{workspace}-{role}
sg-fabric-casino-prod-admins     → Admin role on ws_casino_prod
sg-fabric-casino-prod-members    → Member role on ws_casino_prod
sg-fabric-casino-prod-contributors → Contributor role on ws_casino_prod
sg-fabric-casino-prod-viewers    → Viewer role on ws_casino_prod

sg-fabric-federal-prod-admins    → Admin role on ws_federal_prod
sg-fabric-federal-prod-viewers   → Viewer role on ws_federal_prod

sg-fabric-shared-gold-viewers    → Viewer role on ws_shared_gold

Best Practice: Use dynamic Entra ID groups based on department or job title attributes for automatic role assignment. Example: All users with department = "Casino Operations" automatically join sg-fabric-casino-prod-viewers.

Multi-Workspace Access Pattern¶

flowchart LR
    subgraph Groups["Entra ID Security Groups"]
        style Groups fill:#6C3483,color:#fff
        G1[sg-casino-admins]
        G2[sg-casino-analysts]
        G3[sg-federal-admins]
        G4[sg-federal-analysts]
        G5[sg-shared-viewers]
    end

    subgraph Workspaces["Fabric Workspaces"]
        style Workspaces fill:#2471A3,color:#fff
        W1[ws_casino_prod]
        W2[ws_casino_dev]
        W3[ws_federal_prod]
        W4[ws_federal_dev]
        W5[ws_shared_gold]
    end

    G1 -->|Admin| W1
    G1 -->|Admin| W2
    G2 -->|Viewer| W1
    G2 -->|Contributor| W2
    G3 -->|Admin| W3
    G3 -->|Admin| W4
    G4 -->|Viewer| W3
    G4 -->|Contributor| W4
    G5 -->|Viewer| W5

📦 Item-Level Permissions¶

When to Use Item Permissions¶

Workspace roles apply to all items in a workspace. Item-level permissions provide fine-grained access to specific artifacts without changing workspace membership:

Item Permission Types¶

Sharing Items Without Workspace Access¶

# Share a specific report with an external user via Fabric REST API
import requests

headers = {"Authorization": f"Bearer {access_token}"}
body = {
    "recipients": [
        {"emailAddress": "auditor@external-firm.com"}
    ],
    "permissions": "Read",
    "notifyRecipient": True,
    "message": "Access to the Q1 Compliance Dashboard"
}

response = requests.post(
    f"https://api.fabric.microsoft.com/v1/workspaces/{workspace_id}/reports/{report_id}/shares",
    headers=headers,
    json=body
)

Important: Item-level sharing does NOT grant workspace membership. The shared user sees only the specific item, not the workspace in the navigation pane.

🔒 Data Security¶

Data security in Fabric operates at three levels within Direct Lake semantic models and SQL endpoints:

Row-Level Security (RLS)¶

RLS filters rows based on the signed-in user's identity. Users see only the data they are authorized to access.

Static RLS (Fixed Values)¶

Use when roles map to fixed data partitions:

// DAX filter for the "Eastern Region Analysts" role
[region] = "East"

-- SQL predicate for the "Las Vegas Property" role (SQL endpoint)
CREATE SECURITY POLICY PropertyFilter
ADD FILTER PREDICATE dbo.fn_property_filter(@property_id)
ON dbo.fact_slot_metrics;

Dynamic RLS (User-Based)¶

Use when data filtering depends on the signed-in user's identity:

// DAX filter: Users see only their assigned properties
// Uses a security mapping table: dim_user_property (user_email, property_id)
[property_id] IN
    SELECTCOLUMNS(
        FILTER(
            dim_user_property,
            dim_user_property[user_email] = USERPRINCIPALNAME()
        ),
        "property_id", dim_user_property[property_id]
    )

-- SQL dynamic RLS: Filter by signed-in user's agency
CREATE FUNCTION dbo.fn_agency_filter(@agency_code VARCHAR(10))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS result
WHERE @agency_code IN (
    SELECT agency_code
    FROM dbo.dim_user_agency
    WHERE user_email = SESSION_CONTEXT(N'user_email')
);

RLS Testing¶

Always test RLS filters before publishing:

// In Power BI Desktop → Modeling → "View as" to simulate roles
// Verify: Gaming Director sees all properties
// Verify: Floor Manager sees only their property
// Verify: Analyst sees only their assigned machines

Column-Level Security (CLS)¶

CLS restricts access to specific columns. Users without permission see NULL or an error when querying masked columns.

-- Grant access to SSN column only to compliance officers
GRANT SELECT ON dbo.dim_player (
    player_id, first_name, last_name, email, phone
) TO [sg-casino-analysts];

-- Full column access for compliance
GRANT SELECT ON dbo.dim_player TO [sg-casino-compliance];

Object-Level Security (OLS)¶

OLS hides entire tables or columns from users in semantic models. Hidden objects do not appear in field lists, DAX queries return errors if referenced.

// Semantic model role definition (TMSL)
{
  "name": "HideSensitiveTables",
  "tablePermissions": [
    {
      "name": "fact_ctr_filings",
      "metadataPermission": "none"
    },
    {
      "name": "fact_sar_filings",
      "metadataPermission": "none"
    }
  ]
}

When to use OLS vs CLS: - OLS hides entire tables or columns from the metadata — users cannot even see that the object exists - CLS allows users to see the column exists but returns NULL/error for unauthorized queries - Use OLS for highly sensitive compliance tables (CTR, SAR); use CLS for PII columns in shared tables

Combined Data Security Architecture¶

flowchart TB
    subgraph User["User Query"]
        style User fill:#27AE60,color:#fff
        Q[SELECT * FROM fact_slot_metrics]
    end

    subgraph Security["Data Security Layers"]
        style Security fill:#6C3483,color:#fff
        OLS_Check{OLS: Table visible?}
        CLS_Check{CLS: Column permitted?}
        RLS_Check{RLS: Row filter applies}
    end

    subgraph Result["Query Result"]
        style Result fill:#2471A3,color:#fff
        R[Filtered dataset:<br/>Visible tables only<br/>Permitted columns only<br/>Authorized rows only]
    end

    Q --> OLS_Check
    OLS_Check -->|Yes| CLS_Check
    OLS_Check -->|No - table hidden| X[Error: object not found]
    CLS_Check -->|Permitted| RLS_Check
    CLS_Check -->|Denied| N[NULL / error for column]
    RLS_Check --> R

🤖 Service Identity¶

Workspace Identity (GA 2026)¶

Workspace Identity is a Fabric-native managed identity assigned to a workspace. It replaces the need for separate Azure Managed Identities or Service Principal configurations for workspace-to-Azure-resource authentication.

// Workspace Identity is configured at the Fabric workspace level
// See: infra/modules/security/workspace-identity.bicep

// Grant workspace identity access to storage
resource storageRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(storageAccount.id, 'Storage Blob Data Contributor', workspaceIdentityObjectId)
  scope: storageAccount
  properties: {
    roleDefinitionId: subscriptionResourceId(
      'Microsoft.Authorization/roleDefinitions',
      'ba92f5b4-2d11-453d-a403-e96b0029c9fe' // Storage Blob Data Contributor
    )
    principalId: workspaceIdentityObjectId
    principalType: 'ServicePrincipal'
  }
}

Use cases for Workspace Identity:

Service Principal for CI/CD¶

Service Principals are used for automated deployment pipelines (GitHub Actions, Azure DevOps):

# .github/workflows/deploy-fabric.yml (excerpt)
- name: Deploy Fabric items
  env:
    AZURE_CLIENT_ID: ${{ secrets.FABRIC_SPN_CLIENT_ID }}
    AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
    AZURE_CLIENT_SECRET: ${{ secrets.FABRIC_SPN_CLIENT_SECRET }}
  run: |
    python scripts/fabric-cicd-deploy.py \
      --workspace ws_casino_prod \
      --items-path ./fabric-items/

SPN Permission Requirements:

Security Note: Store SPN credentials in GitHub Secrets or Azure Key Vault. Never hardcode client secrets in code or pipeline definitions. Prefer federated credentials (OIDC) for GitHub Actions to avoid secrets entirely.

Managed Identity for Azure Resources¶

Use Azure Managed Identities (system-assigned or user-assigned) for Azure-hosted compute that interacts with Fabric:

# Azure Function authenticating to Fabric with Managed Identity
from azure.identity import DefaultAzureCredential
import requests

credential = DefaultAzureCredential()
token = credential.get_token("https://api.fabric.microsoft.com/.default")

headers = {"Authorization": f"Bearer {token.token}"}
response = requests.get(
    "https://api.fabric.microsoft.com/v1/workspaces",
    headers=headers
)

Identity Selection Guide¶

flowchart TD
    Start[Need programmatic access?] -->|Yes| Q1{Running inside Fabric?}
    Start -->|No - human user| Entra[Entra ID user + MFA]

    Q1 -->|Yes - notebook/pipeline| WI[Use Workspace Identity]
    Q1 -->|No - external| Q2{Running in Azure?}

    Q2 -->|Yes - Azure VM/Function| AMI[Use Azure Managed Identity]
    Q2 -->|No - CI/CD pipeline| SPN[Use Service Principal]

    style Start fill:#6C3483,color:#fff
    style WI fill:#27AE60,color:#fff
    style AMI fill:#27AE60,color:#fff
    style SPN fill:#E67E22,color:#fff
    style Entra fill:#2471A3,color:#fff

🎰 Casino RBAC Model¶

Organizational Hierarchy¶

The casino gaming industry has a well-defined operational hierarchy that maps directly to Fabric RBAC:

flowchart TB
    subgraph Exec["Executive Level"]
        style Exec fill:#6C3483,color:#fff
        CEO[VP of Gaming / CEO]
        Compliance[Chief Compliance Officer]
    end

    subgraph Mgmt["Management Level"]
        style Mgmt fill:#2471A3,color:#fff
        GD[Gaming Director<br/>Multi-property]
        FM[Floor Manager<br/>Single property]
        CM[Compliance Manager]
    end

    subgraph Ops["Operations Level"]
        style Ops fill:#27AE60,color:#fff
        SA[Slot Analyst]
        TA[Table Games Analyst]
        DA[Data Analyst]
    end

    subgraph Audit["Audit Level"]
        style Audit fill:#E67E22,color:#fff
        IA[Internal Auditor]
        EA[External Auditor / NIGC]
    end

    CEO --> GD
    CEO --> Compliance
    Compliance --> CM
    GD --> FM
    FM --> SA
    FM --> TA
    FM --> DA
    CM --> IA

Casino Role-to-Permission Mapping¶

Property-Based RLS (Casino)¶

Casino operators often manage multiple properties (hotels/casinos). RLS ensures each property's data is isolated:

// RLS filter expression for fact_slot_metrics
// Maps user email → property_id via dim_user_property security table

VAR CurrentUser = USERPRINCIPALNAME()
VAR UserProperties =
    SELECTCOLUMNS(
        FILTER(
            dim_user_property,
            dim_user_property[user_email] = CurrentUser
        ),
        "pid", dim_user_property[property_id]
    )
RETURN
    [property_id] IN UserProperties

Security mapping table (dim_user_property):

NIGC Compliance Access Controls¶

Callout — Auditor Access Pattern: External auditors (NIGC, state gaming commissions) receive item-level permissions on specific compliance reports — never workspace membership. Access is time-bounded using Entra ID access reviews with automatic expiry.

🏛️ Federal RBAC Model¶

PIV/CAC Authentication¶

Federal agencies require phishing-resistant authentication using Personal Identity Verification (PIV) or Common Access Card (CAC) smartcards:

// Entra ID Conditional Access Policy — Require PIV/CAC for Fabric
{
  "displayName": "CA-Federal-Require-PhishingResistant-Fabric",
  "conditions": {
    "applications": {
      "includeApplications": ["powerbi-service-guid"]
    },
    "users": {
      "includeGroups": ["sg-federal-all-users"]
    }
  },
  "grantControls": {
    "authenticationStrength": {
      "requirementsSatisfied": "phishingResistantMFA"
    }
  }
}

Agency Boundary Isolation¶

Each federal agency operates within its own workspace boundary. Cross-agency data sharing requires explicit approval:

flowchart TB
    subgraph USDA_Boundary["USDA Boundary"]
        style USDA_Boundary fill:#27AE60,color:#fff
        WS_USDA[ws_usda_prod]
        LH_USDA[lh_bronze_usda<br/>lh_silver_usda<br/>lh_gold_usda]
    end

    subgraph SBA_Boundary["SBA Boundary"]
        style SBA_Boundary fill:#2471A3,color:#fff
        WS_SBA[ws_sba_prod]
        LH_SBA[lh_bronze_sba<br/>lh_silver_sba<br/>lh_gold_sba]
    end

    subgraph NOAA_Boundary["NOAA Boundary"]
        style NOAA_Boundary fill:#E67E22,color:#fff
        WS_NOAA[ws_noaa_prod]
        LH_NOAA[lh_bronze_noaa<br/>lh_silver_noaa<br/>lh_gold_noaa]
    end

    subgraph Shared["Cross-Agency Shared (Approved)"]
        style Shared fill:#6C3483,color:#fff
        WS_Shared[ws_crossagency_gold]
        LH_Shared[lh_gold_shared<br/>Pre-approved aggregates only]
    end

    WS_USDA -->|Approved shortcut| WS_Shared
    WS_SBA -->|Approved shortcut| WS_Shared
    WS_NOAA -->|Approved shortcut| WS_Shared

Federal Role Mapping¶

Cross-Agency Data Sharing Protocol¶

sequenceDiagram
    participant USDA as USDA Data Steward
    participant Approval as Cross-Agency<br/>Approval Board
    participant Shared as ws_crossagency_gold
    participant SBA as SBA Analyst

    USDA->>Approval: Request to share crop_production_summary
    Approval->>Approval: Review data classification (CUI? PII?)
    Approval-->>USDA: Approved (aggregates only, no PII)
    USDA->>Shared: Create OneLake shortcut to gold_crop_summary
    Shared->>Shared: Apply RLS (agency-scoped views)
    SBA->>Shared: Query gold_crop_summary
    Shared-->>SBA: Filtered results (SBA-approved columns only)

FedRAMP Access Controls¶

FISMA Continuous Monitoring Integration¶

# Export Fabric workspace role assignments for FISMA POA&M reporting
import requests

headers = {"Authorization": f"Bearer {access_token}"}

# Get workspace role assignments
response = requests.get(
    f"https://api.fabric.microsoft.com/v1/workspaces/{workspace_id}/roleAssignments",
    headers=headers
)

assignments = response.json()["value"]

# Format for FISMA reporting
for a in assignments:
    print(f"User: {a['principal']['displayName']}, "
          f"Type: {a['principal']['type']}, "
          f"Role: {a['role']}, "
          f"Last Reviewed: {a.get('lastReviewed', 'N/A')}")

Callout — Agency Isolation is Non-Negotiable: Never grant cross-agency access at the workspace level. Use the shared workspace pattern with OneLake shortcuts pointing to pre-approved, aggregated Gold tables only. Individual-level data never leaves the agency boundary.

🔄 Lifecycle & Governance¶

Access Review Cadence¶

Entra ID Access Reviews Configuration¶

// Auto-expiring access review for casino compliance workspace
{
  "displayName": "Quarterly Review - ws_casino_prod Membership",
  "scope": {
    "resourceId": "ws_casino_prod_group_id",
    "roleId": "member"
  },
  "reviewers": [
    {"query": "/groups/sg-casino-admins/members"}
  ],
  "settings": {
    "recurrence": {
      "pattern": {"type": "absoluteMonthly", "interval": 3}
    },
    "autoApplyDecisionsEnabled": true,
    "defaultDecision": "Deny",
    "justificationRequiredOnApproval": true
  }
}

Permission Change Audit Query¶

// Track workspace permission changes in the Unified Audit Log
FabricAuditLogs
| where OperationName in ("AddWorkspaceUser", "RemoveWorkspaceUser", "UpdateWorkspaceAccess")
| project
    Timestamp = TimeGenerated,
    Operation = OperationName,
    TargetUser = tostring(parse_json(Properties).targetUserEmail),
    NewRole = tostring(parse_json(Properties).role),
    PerformedBy = tostring(parse_json(Properties).performedBy),
    WorkspaceName = tostring(parse_json(Properties).workspaceName)
| order by Timestamp desc

Offboarding Checklist¶

When a user leaves the organization or changes roles:

• Remove from all Fabric workspace security groups
• Revoke item-level sharing permissions
• Update RLS security mapping tables (remove user rows)
• Rotate any shared credentials the user had access to
• Review and update Conditional Access policies if user was in an exception group
• Archive audit logs for the user's access history
• Notify workspace Admins of the access change

⚠️ Common Pitfalls¶

📚 References¶

Microsoft Documentation¶

• Workspace roles in Fabric
• Item permissions
• Row-level security in Fabric
• Column-level security
• Object-level security
• Workspace Identity
• Conditional Access for Fabric

Compliance Standards¶

• NIGC MICS - §542.3, §542.17, §542.31
• FedRAMP AC/IA Control Families
• NIST SP 800-53 Rev. 5 - Access Control
• FISMA Implementation Guide
• HIPAA Access Controls - §164.312(a)

Related Documents¶

• Data Governance Deep Dive — Sensitivity labels, classification, Purview integration
• Outbound Access Protection — Network-level data exfiltration prevention
• Customer-Managed Keys — Encryption key management
• SQL Audit Logs Compliance — Audit logging and compliance reporting
• OneLake Security — OneLake RBAC and shortcut security

Back to Best Practices Index | Back to Documentation