Object level security for contributors - are separate data sets the solution?

[kajetanbocek]

Hi,

at my company we have the following situation:

We are in the process of adding data from a second module of D365 to PBI. The way this is to be done is through a Fabric Link and from there into a PBI semantic model.

The challenge is that we already have a semantic model with data from the finance module in D365 and we need to combine some of the finance data with the data from the second module. So the easy way seems to be to add the tables from the new module to the existing semantic model. Right? At the least it seems it would save some time as we would not need to duplicate the necessary tables from finance in a second semantic model...

The disadvantage of this course of action is that we need to limit access to finance data. For viewer roles we can use object level security for this. But how about contributors? As I understand it OLS does not apply to these. So how do we limit access for them?

After a bit of search it seems like connecting to the existing semantic model in PBI Desktop, making a local copy, removing all non necessary finance tables and saving the dataset to a separate workspace is the way to go.

Will this work? Is this the best way? Are there disadvantages? Alternative ways to achieve this?

Many thanks in advance.

[kajetanbocek]

So, I received the answer that a setup like this should work:

- Workspace A contains a semantic datamodel (D)

- RLS on semantic datamodel (D) which results in user group (C) not seeing any rows in the tables that it should not have access to.
- Workspace B is linked to semantic datamodel (D) but contains only reports.

- User group (C) has contributor role in workspace B.

According to the answer I received, this should allow the users to build in workspace B with contributor rights but wihthout having access to tables with restricted access.

I have not tested this setup, so please inform me (and the rest of the internet) if this does not work.

[v-achippa · Accepted solution]

Hi @kajetanbocek,

Yes this setup will work:

• The important detail is that group C must not have Contributor/Member/Admin access to the workspace that contains the dataset i.e Workspace A, otherwise RLS/OLS will be bypassed.
• Keep the dataset in Workspace A and implement RLS and OLS in that model, grant group C Build permission on that dataset and put reports in Workspace B where group C are Contributors.

This way they can build reports while still being subject to the RLS/OLS defined in the model.

Thanks and regards,

Anjan Kumar Chippa

[v-achippa]

Hi @kajetanbocek,

Thank you for reaching out to Microsoft Fabric Community.

Thank you @audreygerred for the prompt response. 

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user for the issue worked? or let us know if you need any further assistance.

Thanks and regards,

Anjan Kumar Chippa

[audreygerred]

Hi! RLS and OLS should be handled in the semantic model rather than through the workspace and or app. I also recommend pushing reports to an app from the workspace and have report consumers consume from the app.

In the ap you can make audiences and have a report separate reports for each group and one group wouldn't have any visuals from the tables you don't want them to see. However, if we follow least privilege access you would set up RLS or OLS depending on your needs and then still keep report consumers in the app and use audiences as needed.

OLS can be achieved using Tabular Editor 2 (version 2 is free, version 3 is not - but OLS can be achieved with version 2): Object-Level Security (OLS) with Power BI - Microsoft Fabric | Microsoft Learn

Apps in Power BI - Power BI | Microsoft Learn

https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-create-distribute-apps#create-a...

[kajetanbocek]

Hi Audrey,

Thanks a lot for your reply and the suggestions!

I have a follow up question:

Would distributing reports through an app and creating audiences limit contributors access to the semantic data model?

It seems to me like sharing through apps impacts which reports are visible but not which parts of the data model a contributor can see. Please correct me if I misunderstand.

Or maybe giving super users contributor access to a workspace is an outdated way of granting them the necessary access? 

Many thanks in advance.

[audreygerred]

Contributors have access to everything - OLS and RLS do not apply to them. Going back to least privilege access - if people are not actively developing semantic models I do not give them access to a workspace. People that you want to view your reports should access them through the app. If you are in a self-service situation where you want people to utilize the model to do their own reporting they should not have access in your wrkspace, but they should have build access on the semantic model.