Object-level security is one of the key security features in Tabular modeling! Simply said, it enables restricting access to columns or entire tables of the semantic model.
Before OLS was introduced in Power BI, I used a simple RLS trick to hide the whole table from specific users. Let’s say that I want to restrict access to a whole DimGeography table in my semantic model. I can go and do something like this:
I’ve created a role called Hide Geography, selected the DimGeography table, and just put FALSE() as a DAX expression!
Boom! The matrix is completely empty now! That’s fine, but what if I want to hide only specific measure(s), for example, total sales amount (I mean, in reality, you would probably limit access to more sensitive measures than the sales amount, but let’s pretend that only a selected group of people can see total sales amount in our report).
Here comes the Object-level security feature to the rescue!
Wait…How can I control OLS in Power BI?!
Yes, that’s the first…let’s call it limitation! You can’t specify OLS directly from Power BI Desktop – instead, you’ll need an external tool called Tabular Editor.
We’ve already examined some of the features that Tabular Editor provides (for example, creating Calculation groups), and you should definitely use it – be it for OLS, or not. Once you download a free version of Tabular Editor from here, you should be able to access it directly from the Power BI Desktop. Just go to the External Tools tab, and you will see all available external tools (the ones you’ve installed on the same machine where your Power BI Desktop is).
Gotcha #2 – not every Tabular Editor version will work for OLS!
Don’t worry, it’s not about the free vs paid Tabular Editor version, but the “latest” version you have installed on your machine (and, hopefully, you keep your tools up to date, regardless of these specific requirements). In this example, I’m using a 2.11.6 version of Tabular Editor, and I don’t have an option to define OLS!
As soon as I’ve installed the latest version, I can see a whole set of new options for the specific column, one of them being Object Level Security:
Now, instead of Default OLS, I will set the None value to Hide Geography role, for the Sales Amount column:
I will then save the changes made in Tabular Editor, and go back to Power BI Desktop to check what will happen once I start looking at the report as a Hide Geography role member:
Wait, what??!! I’m getting errors within my report! But, why, what did I do wrong? I’ve just restricted access to a Sales Amount measure…
If I’m a user trying to understand what has gone wrong…well, let’s say that I find this message quite awkward:
Gotcha #3 – Don’t try to “understand” the error message!
This strange outcome arises from the fact that when you apply OLS to a certain column, it behaves the same as if you deleted it from your semantic model! And, the following illustration confirms that:
The key difference between RLS and OLS is that, when you apply RLS using DAX filters, data will not be displayed in the report, but the underlying metadata objects still exist in the semantic model!
With OLS, the underlying object (in our example, the Sales Amount column) is completely obscured from the semantic model – in plain words – these objects simply don’t exist for the users who don’t have permission to access them!
Additionally, all measures that refer to the restricted column will also “disappear” from the data model!
Both RLS and OLS in Power BI are powerful features, which give you a whole range of capabilities to control “who sees what” in your Power BI solutions.
However, don’t jump to a quick conclusion that the only difference between the two is the “direction” of the rules applied – horizontal vs vertical. RLS and OLS work in a completely different way – not only because you can’t configure OLS from Power BI itself (unlike RLS) – but more because of the manner in which they “hide” the data from the users: with RLS, objects still exist in the model, while with OLS they are completely omitted!
Thanks for reading!
Last Updated on February 13, 2024 by Nikola