Hi everyone,
I'm trying to understand a confusing aspect of Power BI's ExecuteQueries REST API and service principal authentication with Row-Level Security (RLS).
The Problem
I've been attempting to use service principal authentication with impersonation to query RLS-enabled datasets using the ExecuteQueries API. However, I consistently get 401 Unauthorized errors, regardless of:
- User permissions (workspace admin, regular user, external users)
- RLS role assignments (assigned users directly to RLS roles)
- Impersonation method (identities array vs impersonatedUserName parameter)
- User types (real Azure AD users vs fake usernames)
What Works vs What Doesn't
✅Works perfectly: Service principal + impersonation on non-RLS datasets
❌Always fails: Service principal + impersonation on RLS-enabled datasets
For example, this request works fine on non-RLS datasets:
POST https://api.powerbi.com/v1.0/myorg/groups/{workspaceId}/datasets/{datasetId}/executeQueries
Authorization: Bearer [service_principal_token]
{
"impersonatedUserName": "user@domain.com",
"queries": [{"query": "EVALUATE ROW(\"Price\", [Revenue])"}]
}
But the exact same request fails with 401 on RLS datasets.
Here's where I'm getting confused. The documentation mentions different aspects of the limitation:
From ExecuteQueries REST API docs:
https://learn.microsoft.com/en-us/rest/api/power-bi/datasets/execute-queries
"Service Principals are NOT supported for datasets with Row Level Security (RLS)"
From RLS documentation:
https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security
"Service principals can't be added to an RLS role"
The RLS documentation specifically mentions that "service principals can't be added to an RLS role" - which sounds like the limitation is about ASSIGNING service principals TO roles.
But the ExecuteQueries API documentation says service principals are not supported for RLS datasets AT ALL.
This creates confusion: Are service principals blocked from:
1. Only being assigned to RLS roles directly? OR
2. Working with RLS datasets entirely (even with impersonation)?
My Understanding vs Reality
I thought the impersonation approach would work like this:
- Service principal authenticates (not assigned to any RLS role)
- Service principal uses impersonation to "act as" a real user
- Real user has proper RLS role assignments
- Query executes under the real user's security context
But this doesn't work, suggesting the limitation is broader than just "can't be added to roles."
Why Do Impersonation Parameters Exist?
If service principals fundamentally cannot work with RLS datasets, then why do these impersonation parameters exist in the ExecuteQueries API?
- identities array with username/roles
- impersonatedUserName parameter
These seem specifically designed for RLS scenarios, but if service principals are completely blocked from RLS datasets, what's their actual purpose?
Questions
1. Is the limitation about service principals being assigned to RLS roles, OR about service principals working with RLS datasets entirely?
2. What are the impersonation parameters actually for if service principals can't use them with RLS?
3. Are there any scenarios where service principal + impersonation works with RLS?
4. Is this a permanent architectural limitation or something that might be addressed?
My Use Case
I need programmatic access to RLS datasets with different user contexts for a multi-tenant application. The impersonation approach seemed perfect since I'm not trying to assign the service principal to roles - just use it to impersonate real users who have proper role assignments.
Any clarification on the exact scope of this limitation would be greatly appreciated!
Thanks!
Related Documentation:
- ExecuteQueries REST API: https://learn.microsoft.com/en-us/rest/api/power-bi/datasets/execute-queries
- Service Principal Authentication: https://learn.microsoft.com/en-us/power-bi/developer/embedded/embed-service-principal
- Row-level Security: https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security
