Row-Level Security, Object-Level Security, and Data Protection

1. Foundations of Power BI Security Architecture

The Defense-in-Depth Model

Power BI security operates as concentric rings: tenant governance and Azure AD policies form the outer ring, workspace permissions (Admin, Member, Contributor, Viewer) control artifact access, dataset Build permission governs report creation, and the innermost rings — RLS, OLS, and sensitivity labels — govern the data itself. A critical production pitfall is assuming Workspace Viewer access implies row-level scoping; it does not. RLS must be explicitly configured, and users not assigned to any role see the full dataset.

Users with Power BI Dataset Build permission bypass RLS entirely when connecting via Analyze in Excel or live connections from Power BI Desktop. The architectural response is workspace separation — keep model builders in a development workspace with Build access and data consumers in a production workspace with Viewer-only access, using dataset sharing to bridge them without granting Build rights.

Security Role Artifacts and Lifecycle

RLS roles are model artifacts stored in the .pbix and published with the dataset — modifying a role definition requires republishing from Desktop. Role membership, however, is managed in the Power BI Service without republishing and is typically delegated to workspace admins or business owners. OLS configurations follow the same publication lifecycle; sensitivity labels are applied separately via Desktop, the Service, or automatic inheritance from labeled upstream sources.

2. Static RLS: Role Definition and DAX Filter Expressions

Defining Static Roles in Power BI Desktop

Static RLS roles are defined in Modeling > Manage Roles. Each role is paired with a Boolean DAX table filter expression — Power BI returns only rows for which the expression evaluates to TRUE. Filters should target dimension tables rather than fact tables; Power BI propagates the dimension filter through relationships to downstream fact tables automatically. Filtering the fact table directly is a common mistake that prevents upstream filter propagation.

DAX Filter Expression Patterns

Common static filter patterns: single value ([Region] = "North America"), multi-value set ([Region] IN {"North America","EMEA"}), and substring match (CONTAINSSTRING([SalesRegionCodes],"NA")). Note that filter expressions cannot reference measures or columns from other tables without RELATED or RELATEDTABLE.

Multiple Tables and Role Interaction

A single role can filter multiple tables simultaneously — each table entry adds an independent filter. When a user belongs to multiple roles, Power BI applies the union (OR) of all role filters, not the intersection. If AND semantics are required, merge the conditions into a single role with a compound DAX expression. Workspace Admins, Members, and Contributors bypass RLS entirely; only Viewers and users with direct Read permission are subject to role filters.

3. Dynamic RLS with USERPRINCIPALNAME() and Dimension Tables

Dynamic RLS Architecture

Dynamic RLS uses a single role definition whose DAX filter expression evaluates differently per user at query time. The canonical pattern loads a security mapping table (e.g., UserSecurity) with columns [UserPrincipalName] and [Region], joins it to the Geography dimension via [Region], and sets the role filter on the security table to [UserPrincipalName] = USERPRINCIPALNAME(). The relationship propagates the per-user filter through Geography to the Sales fact table. The security mapping table should be sourced from a live data source — not an "Enter Data" table — so access changes take effect on dataset refresh without republishing the .pbix.

USERNAME() vs. USERPRINCIPALNAME()

USERPRINCIPALNAME() returns the Azure AD UPN (user@domain.com format) and is the recommended function for all modern cloud Power BI deployments. USERNAME() returns DOMAIN\username format — identical to UPN for cloud-only accounts, but different for hybrid AD accounts with mismatched SAM names. Always use USERPRINCIPALNAME() and store UPN values in the security mapping table.

Implementing Dynamic RLS

Five-step pattern: (1) load the security mapping table from a governed live source; (2) create a many-to-one relationship from UserSecurity[Region] to Geography[RegionCode] with single-direction cross-filter; (3) define the role filter; (4) add all data consumers to this single role; (5) handle edge cases — unmatched users see no data (correct default), users with multiple rows see the union of their partitions.

-- Dynamic RLS role filter on UserSecurity table
[UserPrincipalName] = USERPRINCIPALNAME()

-- Manager-subordinate variant (user sees own rows + reports)
[UserPrincipalName] = USERPRINCIPALNAME()
    || [ManagerUPN] = USERPRINCIPALNAME()

4. Object-Level Security: Hiding Tables and Columns

OLS Architecture and Capacity Requirements

Object-Level Security hides tables or columns at the metadata level — hidden objects do not appear in the field list and cannot be referenced in DAX or report visuals by members of the restricted role. OLS requires Premium capacity (Premium Per User or Premium Per Capacity) and datasets using the enhanced metadata format. It is unavailable in shared-capacity Pro workspaces. OLS is configured exclusively through Tabular Editor (free TE2 or commercial TE3) — Power BI Desktop has no native OLS UI.

Configuring Column-Level OLS

In Tabular Editor, expand the table, select the column, open the Security tab in properties, and set MetadataPermission to None for the role to be denied. The valid values are Read (allowed), None (denied — object hidden), and ReadDesign. When a column is OLS-restricted, any measure that references it also becomes inaccessible to the denied role — users receive an error, not empty results.

OLS vs. RLS Decision and Comparison

Use RLS when all users see the same columns but different rows (regional data, cost centers). Use OLS when certain users must not know a column or table exists (salary, PII, competitive intelligence). Combine both for fine-grained governance: RLS scopes rows, OLS scopes columns. OLS and RLS are independent — a table can have both applied to different aspects of the same role.

5. Sensitivity Labels: Applying, Inheriting, and Enforcing MIP Policies

Microsoft Information Protection and Power BI Integration

MIP sensitivity labels (Confidential, Highly Confidential, Internal, etc.) classify data confidentiality and trigger downstream governance policies. Labels applied to Power BI datasets travel with data when exported — Excel, CSV, PowerPoint, and Analyze in Excel connections all inherit the source dataset's label, and the associated MIP policy (encryption, watermarking, access restrictions) is applied to the exported file. Labels are defined in the Microsoft Purview compliance portal and published to Power BI users via label policies.

Applying Labels in Desktop and the Service

In Power BI Desktop, the Sensitivity button in the Home ribbon opens the label picker. The selected label is embedded in the .pbix metadata and published with the dataset. In the Power BI Service, labels can be viewed and changed on datasets, reports, dashboards, and dataflows via artifact settings. Label downgrade (reducing classification) may require business justification and is logged to the Purview audit log for compliance traceability.

Label Inheritance and Downstream Enforcement

When "Automatically apply sensitivity labels from data sources" is enabled at the tenant level, Power BI datasets inherit the highest-classification label from their upstream data sources. This propagates to downstream reports, dashboards, and dataflows. Exported files receive the inherited label and associated Azure Rights Management policy — encryption, forwarding restrictions, and visual watermarks are applied transparently. This creates an auditable governance chain from source classification to exported artifact.

6. Testing RLS and Managing Role Membership

Testing with View as Role in Power BI Desktop

The View as feature (Modeling ribbon) renders the report through a selected role's filter. For static roles, check the role checkbox. For dynamic roles, check the role AND enter a test UPN in the "Other user" field — Power BI substitutes this string as the return value of USERPRINCIPALNAME(). Test with UPNs present in the security table (expect scoped data), absent UPNs (expect no data), and UPNs mapped to multiple partitions (expect union). Document each test case in a test matrix with expected vs. actual row counts.

Managing Role Membership in the Power BI Service

Navigate to the workspace dataset > three-dot menu > Security to add Azure AD users or security groups to each defined role. Adding Azure AD security groups is the recommended pattern — group membership in AAD drives access without requiring any dataset changes. Changes take effect within minutes due to AAD token caching. The Power BI REST API (POST .../datasets/{id}/roles/{role}/members) enables automated membership management integrated with HR and identity governance systems.

Validating RLS in the Power BI Service

Always validate published RLS using real test accounts in the Service — real AAD tokens and group memberships may differ from Desktop simulation. Create two test accounts: one with a role assignment (expects scoped data) and one outside all roles (expects no data or an access message). Verify slicers and drillthrough pages cannot expose out-of-scope data. For dynamic RLS, confirm that accounts absent from the security mapping table return zero rows, not all rows — a mismatch indicates a relationship or filter expression error.

7. Lab: Implementing Dynamic RLS and MIP Sensitivity Labels

# CE-19: Provision Azure SQL and configure Dynamic RLS
RESOURCE_GROUP="rg-rls-ols-data-protection-prod-001"
SQL_SERVER_NAME="rls-ols-prod-eastus2-001"
SQL_DB_NAME="RLSSecurityMappingDB"

az group create --name "$RESOURCE_GROUP" --location "eastus2"
az sql server create --name "$SQL_SERVER_NAME" --resource-group "$RESOURCE_GROUP" \
  --location "eastus2" --admin-user "sqladmin" --admin-password "S3cur3Pa\$\$w0rd!"
az sql db create --resource-group "$RESOURCE_GROUP" --server "$SQL_SERVER_NAME" \
  --name "$SQL_DB_NAME" --service-objective S2
# ... see full script below for SQL table creation and REST API role assignment

# CE-20: Apply MIP label to Power BI dataset via REST API
ACCESS_TOKEN=$(az account get-access-token \
  --resource "https://analysis.windows.net/powerbi/api" \
  --query accessToken -o tsv)

curl -s -X POST \
  "https://api.powerbi.com/v1.0/myorg/datasets/SetLabelAsAdmin" \
  -H "Authorization: Bearer \${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"datasets":[{"id":"<dataset-id>"}],"labelDetails":{"labelId":"<mip-label-id>"}}'
# Verify label on downstream report and query Purview audit log for label events

8. Chapter Summary

Chapter: 10 of 12  |  Status: v0.1 Draft  |  2026-07-08