Embed for customers without giving the user principal membership of the entire workspace

[hholthuis]

Hi,

I'm working on a "embed for you customers" solution in our PowerBi tenant. And I'm struggling to give the service principle the right amount of permissions (enough to work properly but no more than necessary).

I have one workspace "Workspace A" which houses all (20 ish) major semantic models. The majority of reports (1000+) in our tenant are thin reports in other workspaces, linked to any one dataset in "Workspace A" (cross workspace is enabled)

permissions are set at the semantic model level. "Workspace A" has no members or contributors.

For the purpose of this "embed for you customers" project I have a dedicated workspace "Workspace B" which contains all the reports and dashboard we want to embed in our application. These reports are all thin reports, linked to one of the models in "Workspace A"

I have set up a service principal and gave it read/build permissions on the semantic model in "workspace A" and the "member" role in "Workspace B".

However, upon requesting an embed token for the report in "Workspace B" (which uses model in A) I get this error: "PowerBINotAuthorizedException"

Upon inspection of the documentations. It states that the service principal needs at least the "member" role in the worspace where the model resides (Workspace A). So I gave the SP this role and it works. I get an embed token. So it is solved, you'd think. 

However, I don't want to give out the member role to this service principle. Because "Workspace A" has all sorts of semantic models which the Service principal has no business accessing (this includes highly sensitive data). Also, our application is built and maintained by a third party whom should not be able to access any other datasets.

One other solution I got working is to simply copy the required model(s) to "Workspace B" and have the reports connect to that. But this introduces double maintenance. Also, the models are fairly large because of our approach, which eats at our capacity. Hence, I find this solution to be sub-ideal.

Is there any other way I can get this to work?
requirement: service principal has access only to relevant datasets in workspace A

[v-dineshya · Accepted solution]

Hi @hholthuis ,

Thank you for reaching out to the Microsoft Community Forum.

You want to restrict a service principal's access to only specific semantic models in Workspace A, without granting it full workspace membership.

1. According to Microsoft Documentation, a service principal must be a member or admin of the workspace to access its content. This is the reason your embed token fails unless the SP is a member of Workspace A.

2. There is currently no built-in way to restrict a service principal’s access to only specific datasets within a workspace while still allowing cross-workspace embedding. The permission model is workspace-scoped, not dataset-scoped, for SPs.

3. RLS can restrict data visibility for users with Viewer roles, it does not apply to service principals.

Please try below workarounds.

1. Use Separate Workspaces for Sensitive Models. Split Workspace A into two. Workspace A1, Only models needed for embedding and Workspace A2, Sensitive models. Grant the SP member access to A1 only.

Note: This avoids overexposure but requires some reorganization.

2. Use Power BI Deployment Pipelines to manage model from dev to embed environments. This allows you to maintain a clean, minimal model in Workspace B.
Automate updates from Workspace A without manual duplication.

3. Create a Azure AD security group for the SP and assign it only to the required datasets. However, this still requires workspace-level membership unless Microsoft changes the model.

4. If you are embedding reports dynamically, you can use the REST API to bind reports to datasets at runtime. This allows you to Host reports in Workspace B. Bind them to datasets in Workspace A, if SP has access. But the SP must be a member of Workspace A.

Please refer below Microsoft official document.

Embed Power BI content in an embedded analytics application with service principal and an applicatio...

If this information is helpful, please “Accept it as a solution” and give a "kudos" to assist other community members in resolving similar issues more efficiently.
Thank you.

[hholthuis]

Thank you for the clear explanation. I expected as much but still thank you for confirming.

About the workarounds

1. This solution did come to mind and is perfectly reasonable. I'd have to rebind all the existing reports though but that can be scripted.
2. Do you mean to 'abuse' deployment pipelines and make Workspace B the next stage of Workspace A and then deploy and update only the required models? If so, this does remove the double maintanance issue. It does not remove the double model-size impact however. Still, it's a clever idea I did not think of myself.
3. SP is already in a security group and through which all permissions are managed. I fail to see how this would help with anything.
4. Also nice technique but I dont see how this solves anything. Like you say, SP still needs membership of Workspace A

I'm going to try @Deku's suggestion (because it's a low effort hail mary).
And if that fails I'll go with workaround #1

Thank you all for thinking with me.

[Deku]

You could always try setting up a composite model in workspace B.

[hholthuis]

Thank you for your suggestion. I believe I read somewhere that de Service Principal still needs membership of the workspace with the direct query source. 

However I have not tried this yet so I will, and I'll return with my findings