Setting up a shareable cloud connection to a semantic model

[Luuk_]

Hi all,

Scenario: 

• We have a Power BI Premium Workspace that contains several semantic models, let's call this one workspace A;
• We have another Power BI Premium workspace which contains reports, build upon data from the models in workspace A using Direct query connection, combined with other data sources (composite model, so it has its own semantic model in this workspace) let's call this workspace B;

In order for users, who have access to the reports in workspace B, to view the data, they also need read permissions on the model(s) in workspace A. I could add them all individually but that will soon become unmanageable.

So I’m looking for a way to use a service principle or the workspace identity to connect my semantic model in workspace B to the one in workspace A (fixed identity). However, when creating a shareable cloud connection to the model in workspace A, there is no other option available besides Basic and OAuth 2.0 for authentication methods.
We have a service principle in place, used to access the Power BI Admin Rest API's with all necessary options enabled (both in Azure as well as within Power BI).

What am I missing or what options do I have?

[Anonymous]

Hi @Luuk_,

Thanks for reaching out to the Microsoft fabric community forum.

Just following up to your previous message, I'd like to confirm if you've successfully resolved this issue or if you need further help.

If yes, you are welcome to share your workaround and mark it as a solution so that other users can benefit as well. If you find a reply particularly helpful to you, you can also mark it as a solution.

I would also take a moment to thank @ibarrau, for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.

If I misunderstand your needs or you still have problems on it, please feel free to let us know.  

Best Regards,
Hammad.
Community Support Team

If this post helps then please mark it as a solution, so that other members find it more quickly.

Thank you.

[Luuk_]

The example is indeed for a situation where you have everything in the same workspace, but the basics should work across workspaces as well.

But like you said before; it all comes down to the connector used.
I guess the documentation on authenticating with a workspace identity also threw me off a bit, since it says it can also be used on Power BI Semantic Models. Looking more closely: probably only for import mode.

Using a service account is a good option, to replace my personal login within the connection. That is in the connection from the model in workspace B to the one in Workspace A.
But that would still require me to add each user group individually to the model in workspace A right?
Or should SSO be turned off? Tried that before but that gave me an error: “An error occurred in Power BI Premium backend services. Please see the error details for additional information.”

[ibarrau · Accepted solution]

Shared source will let developers to build new semantic models, publish and keep a single standard configuration for the refreshes. That only works for refresh data and nothing else. Then you still need to make sure the user that has access to a report also can read the semantic model. I don't think you can get rid of that. Maybe there is a trick for import but for direct query sounds almost impossible.

If you would really really want to separate that. Forget for ever of the semantic model permission for users. I guess the best alternative is embedding in ISV. Embedded software will configure all that for a single service principal and become owners of the distribution and login. They keep who can se what report (assign people manually to report) and forget about models. An example would be https://www.pibi.cloud

I hope that make sense

[Luuk_]

I guess looking for other solutions, like within a Fabric environment and Direct Lake mode, would be our best approach. With our current P1 license, it's just a matter of turning on Fabric, which is something we're looking into right now.

Thanks for the help!

[ibarrau]

Hi. Not all the connection will have the same authentication methods. Some will let you use service principal and others won't. I think the shared connection is a feature for letting many semantic models authenticate in a single way by different people preventing each development to keep different credentials.

In your case, it looks like you are worried about sharing the model one by one if it increase the people involved. In that scenario I would share the semantic model (manage permission) with a Entra ID Security Group. The same for the report. That way you would just add people to a security ground and make sure everything is ready to go for them.

I hope that helps,

[Luuk_]

Thanks for the reply!

We do use Entra ID Security groups on all our products, we never authorized an individual user. 

The thing is, the models in workspace A are master models, used in many workspaces/reports. All with different audiences. So even with using Entra ID security groups it would still become unmanageable at some point. Especially when access also needs to be maintained (removing groups from the model) on the models in workspace A.

I'm looking for a solution as shown in this video from Guy (Gal) in a Cube: Using fixed Identity  

[ibarrau]

That example is showing two semantic models at the same workspace. Shows how to create a shared connection to a Fabric Data Warehouse that could be use for any semantic model. Probably direct lake or import connection at models. That's why it allows Service Principal. On your example, you are working with direct query to a semantic model source. That's totally different. Like I said, sources won't work the same way. You can create a shared connection to a semantic model with AAS connector probably but it will use Entra ID credentials. You could create a service account for that instead of a service principal as an alternative.

I hope that helps