Forum Discussion
Controlled "Semantic Model Execute Queries" REST API Access for Fabric Users
Yeah I hear you sean_cochran ! But unfortunately that is not possible with today's security model, currently you can’t say “allow this user’s Power BI token only to this item or when it comes from this trusted application”; the way forward is to change which identity is allowed to call the API, or to reconsider how much new risk the API actually adds and decide whether is the risk is acceptable base on the data and its sensitivity.
Furthermore, you also need to take in consideration that, whatever the tenant setting, Service Principals aren’t supported for datasets with RLS per RLS limitations or datasets with SSO enabled.
Not many option on this case, the only one that I can think of is to use a dedicated service user account and scope the “Semantic Model Execute Queries REST API” tenant setting to a group containing only that account and the flow would work like this...
#1. The user signs in to your app and gets an ordinary Entra token
#2. The app gets a Power BI token as the service account (e.g. [email protected])
#3. The app calls the API and names the end user.
POST https://api.powerbi.com/v1.0/myorg/groups/{workspaceId}/datasets/{datasetId}/executeQueries
Authorization: Bearer <service account token>
{
"queries": [{ "query": "EVALUATE TOPN(10, Sales)" }],
"impersonatedUserName": "[email protected]"
}
#4. Model applies user's row-level security (RLS) roles and returns only what she is allowed to see.
But there's some many "buts" that I can hardly see you guys going thru this path, I'm just want to give you options 😅
This is my cents on your post, hope you find some of this information useful; would it be nice a thumbs up and mark as solution if deemed appropriate.... wish you the very best.
- sean_cochran1 day ago
Resolver I
Thanks for the response! I really appreciate your engagement with this issue. The impersonatedUserName path would work, but switching to an entra user makes authentication a manual, error-prone process for the application. An admin has to get a token initially via a manual process like a browser-based credential, the application has to make routine calls to refresh it, and if Microsoft unexpectedly force-expires the refresh token, the application becomes unusable until an admin finds out (probably via complaints from users) and reauthenticates via the same manual process. We don't want to offer an application that fails unexpectedly and requires manual intervention to recover. Given Microsoft's own guidance to avoid using entra users as service accounts, I hope they provide an officially-sanctioned pathway for this in the future - maybe rethinking how service principals interact with RLS-enabled models.