Forum Discussion
Embed Token Generation Successful, but 403 Forbidden on ExecuteQueries API
Hi KonradKolenda ,
Thanks for sharing the additional details. You are correct that the guidance recommends using a service principal for production apps and that the documentation indicates arbitrary strings can be used for RLS when generating embed tokens.
The executeQueries API examples are shown with Azure AD access tokens from a service principal or master user, and there does not seem to be a way to pass an arbitrary identity through that API call in the same way it is done when generating an embed token. This may explain why the combination of service principal, arbitrary usernames, and executeQueries is not working as expected.
Based on research and documentation, the executeQueries endpoint does not appear to support supplying an effective identity in the request body. That option is described only in the context of token generation for embedding. If the main requirement is enforcing RLS with non-AD usernames, embedding reports or using embed tokens may still be the supported approach. For programmatic queries, alternatives like XMLA endpoints could be considered, but those require valid AAD identities and do not accept arbitrary strings.
This seems to be a gap between the supported scenarios, and if this combination is critical for your use case it may be best to raise it through support ticket to confirm whether there is a way planned to enable it.
Hope this helps. Please reach out for further assistance.
Thank you.
Hi v-veshwara-msft ,
Thank you for you answer.
I do have a follow-up question though, and I'm hoping you can help us figure out the best path forward.
We've been following Microsoft's guidance pretty closely, and according to your documentation, we should be using service principal authentication - [implementation planning guide](https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-usage-scenario-embed-for-your-customers) is pretty clear about this:
"We recommend using a service principal for production apps. It provides the highest security and for this reason it's the approach recommended by Microsoft Entra ID."
We're also using "arbitrary usernames" approach which are users that don't exist in Azure AD. [Cloud RLS documentation](https://learn.microsoft.com/en-us/power-bi/developer/embedded/cloud-rls) docs say this is totally fine: "when you generate the embed token, you need to supply a username, but the username can be any string".
Here's where I'm getting stuck:
- Service Principal authentication = Microsoft recommended ✅
- Non-AD usernames for RLS = Officially supported ✅
- ExecuteQueries API = What we need for direct dataset access ✅
- All three working together = Apparently not possible? ❌
So my question is: How are we supposed to do RLS with arbitrary usernames when using executeQueries with service principal authentication?
Is there a way to pass the user identity context in the executeQueries request body? Or should we be using a completely different approach for this scenario?
I feel like we're trying to follow all the "right" Microsoft patterns, but they don't seem to play nicely together for our use case. Any guidance on how to make this work (or if there's a better approach) would be really helpful!
Hi KonradKolenda ,
Thanks for sharing the additional details. You are correct that the guidance recommends using a service principal for production apps and that the documentation indicates arbitrary strings can be used for RLS when generating embed tokens.
The executeQueries API examples are shown with Azure AD access tokens from a service principal or master user, and there does not seem to be a way to pass an arbitrary identity through that API call in the same way it is done when generating an embed token. This may explain why the combination of service principal, arbitrary usernames, and executeQueries is not working as expected.
Based on research and documentation, the executeQueries endpoint does not appear to support supplying an effective identity in the request body. That option is described only in the context of token generation for embedding. If the main requirement is enforcing RLS with non-AD usernames, embedding reports or using embed tokens may still be the supported approach. For programmatic queries, alternatives like XMLA endpoints could be considered, but those require valid AAD identities and do not accept arbitrary strings.
This seems to be a gap between the supported scenarios, and if this combination is critical for your use case it may be best to raise it through support ticket to confirm whether there is a way planned to enable it.
Hope this helps. Please reach out for further assistance.
Thank you.