Service Principal + RLS + ExecuteQueries REST API

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

          3. 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