Service Principal + RLS + ExecuteQueries REST API

KonradKolenda — Fri, 22 Aug 2025 20:31:28 GMT

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

Re: Service Principal + RLS + ExecuteQueries REST API

johnbasha33 — Sat, 23 Aug 2025 07:13:04 GMT

Hi The crux

The ExecuteQueries API explicitly says: “Service principals aren’t supported for datasets with RLS …” (also not supported for SSO-enabled models). That’s a blanket restriction on this API path, not just on role assignment. Microsoft Learn
The RLS article says: “Service principals can’t be added to an RLS role. Accordingly, RLS isn’t applied for apps using a service principal as the final effective identity.” That’s about who the engine ultimately treats as the user when evaluating security. Microsoft Learn

Put together: a service principal calling ExecuteQueries against an RLS-enabled dataset—even with impersonatedUserName or identities—is blocked (401). Your behavior matches the spec.

Why do impersonation parameters exist then?

Because they’re used in other supported flows:
1. ExecuteQueries with a user token (delegated auth)
  If the caller is an actual Entra user (not an SP), impersonatedUserName lets admins/testers run queries “as” another user on an RLS model. The parameter is documented on the API and is honored—but only when the API itself is allowed (i.e., not SP on RLS). Microsoft Learn
2. Embedding with EffectiveIdentity (GenerateToken)
  In App-Owns-Data embedding, an SP can generate an embed token that carries an EffectiveIdentity (identities/username/roles). RLS is then applied for that effective user when rendering embedded content. This is the supported way to do multi-tenant, per-user RLS with an SP—for embedding, not for ExecuteQueries. Microsoft Learn+2Microsoft Learn+2
  
  Direct answers to your questions
  1. Is the limitation about SPs-in-roles or SPs-with-RLS-datasets entirely?
    For ExecuteQueries it’s the latter: SPs can’t call ExecuteQueries on RLS datasets at all (401), regardless of impersonation. Microsoft Learn
  2. What are the impersonation params for if SPs can’t use them with RLS?
    They’re for:
    - User-token calls to ExecuteQueries (admin/test scenarios), and
    - Embedding via GenerateToken (EffectiveIdentity), which does apply RLS for the specified username. Microsoft Learn+1
      1. Any scenario where SP + impersonation works with RLS?
        Yes—embedding with an SP that generates an embed token including an EffectiveIdentity (username/roles). RLS is enforced for that identity at render time. Not supported for SP + ExecuteQueries. Microsoft Learn+1
        
        Permanent architectural limitation?
        As of today (Aug 23, 2025), Microsoft’s docs still state the restriction; there’s no public roadmap indicating a change. Treat it as a hard constraint for the ExecuteQueries API.
        
        Did I answer your question? Mark my post as a solution! Appreciate your Kudos !!

@KonradKolenda

topic Re: Service Principal + RLS + ExecuteQueries REST API in Developer

Service Principal + RLS + ExecuteQueries REST API

Re: Service Principal + RLS + ExecuteQueries REST API

Why do impersonation parameters exist then?

Direct answers to your questions