Object Level Security (OLS) helps meet the most demanding requirements to protect and secure your valuable data assets. In addition to Row Level Security (RLS) that helps restrict access to the rows filtered by DAX statements, OLS prevents access to columns or even complete tables.
OLS is introduced to Power BI datasets in February 2021 as a preview feature. If you require OLS in a production environment, you might consider using Azure Analysis Service (AAS). AAS supports OLS for a long time in production environments
At the time of this writing (February 2021), the user interface (UI) of Power BI Desktop does not support OLS configuration. Instead, we can use Tabular Editor to configure OLS as mentioned in the article that announced the availability of OLS in preview
Announcing public preview of Object-Level Security in Power BI | Microsoft Power BI Blog | Microsoft Power BI
The most important thing about OLS is the simple fact that it is possible to apply OLS to a table and a single column.
The reason why I'm advocating the separation of workspaces (the data workspace and content workspace), both types of security RLS and OLS, will be honored during content creation if the report creator does not belong to the data workspace.
The data model
To demonstrate OLS, I use a very simple data model build by three tables. A simple calendar table, an even more simple dimension table, and of course, a fact table. The next picture shows this data model:
The configuration of OLS
I use Tabular Editor to configure OLS. If you are not familiar with Tabular Editor, start here:
Tabular Editor. In addition to that, it could be possible that you are also not familiar with the feature "External tools," here you will find another article that introduces this feature: Using external tools in Power BI (preview) - Power BI | Microsoft Docs
The configuration of OLS is quite simple and similar to the configuration of RLS. Here are the steps:
1. Define a role in Power BI Desktop
2. Configure RLS using Power BI Desktop
3. Configure OLS using Tabular Editor
4. Publish the pbix to the data workspace
5. Assign users to the roles using inside Power BI Service.
The configuration of OLS
Assuming there are these requirements/conditions to define a role:
· Deny complete access to the table Dimension
· Deny access to the Date column of the Calendar table
· Restrict access to the year 2021 of the Calendar table
I will create one role that I name "Restricted Access" that implements OLS and RLS's above requirements and assign users with restricted access to this role. A 2nd "Admin Access" to implement unrestricted access to the data model.
The next picture shows how to configure the RLS part for the role "Restricted Access"
The next two pictures are showing the configuration of OLS using Tabular Editor. The first picture shows how to deny access to the complete table "Dimension."
The next picture shows how to deny access to the column Date of the Calendar table:
After the role is configured, the above steps must be repeated for all other roles. As this is just a simple example it's not necessary to configure OLS for other roles.
The pbix can be published to the workspace and users (better Azure Security Groups) can be assigned to the roles.
The next picture shows how users can be assigned to the roles (mark the dataset and select Security from the options menu):
Please be aware that the title of the dialog is somewhat misleading, even if the dialog is called "Row-Level-Security", users will be assigned to roles just once. There is no 2nd dialog needed.
The next picture shows what happens when the user tomtom connects to the Power BI dataset inside the workspace "the data workspace".
Please be aware that I follow the paradigm of workspace separation (two separate workspaces, one that holds the datasets, the other one the content), here the content creator is not assigned to "the data workspace". This user has just the dataset permissions build and read assigned.
OLS will help to protect our data assets.
Have fun, thanks for reading.