Introduction to OLS
Object-level security (OLS) enables you to restrict access to objects in Power BI, which includes tables and columns. Once enabled, the data is secured along with the metadata, and so the existence of that object is completely hidden from the user.
Need for Object-level security
Object-level security provides masking of sensitive column fields and their metadata. This method can hide tables and columns. These tables and fields cannot be viewed even when you make use of Microsoft Excel or other reporting tools like Power BI. The user can also not access these fields even while using DAX to reference them in any calculation or creation of calculated fields. It is completely non-existent to other users.
Row-level security Vs. Object-level security
| Row-level security | Object-level security |
| Protect data by assigning roles. | Protect objects by hiding and restricting them from users. |
| Metadata of objects can be viewed. | Metadata of objects cannot be viewed. |
| Filters are specified using DAX, and roles can be changed within the Power BI desktop. | Roles can be managed for object-level security external tools like the tabular editor. |
Object-level security in action
You can enable object-level security with the following tools:
- Power BI Desktop – external tools like Tabular Editor.
- Power BI Service – XMLA endpoint using TMSL or TOM.
Configure OLS using Tabular Editor
To enable object-level security, you first create roles in Power BI Desktop. You can do this by navigating to the below tab in Power BI Desktop.
From a sample dataset, we have restricted the users to view only region east data.
The row-level security is created on the region field, and another role enabling OLS is created under the non-financial role.
To enable OLS, the column level permission is edited. We can find this under OLS column permissions.
Please note to enable object-level security, edit permissions should be enabled in the tabular editor preferences as attached below. Without enabling it, the permissions for columns or tables cannot be edited.
The same can be tested from the Power BI Service by viewing the report in a particular role that has been created.
XMLA endpoint enablement for OLS with Power BI Premium
You will need admin-level access to make use of the XMLA endpoint for OLS with Power BI Premium. Making use of TOM (Tabular Object Model) or TMSL (Tabular Model Scripting Language) TMSL communicates with Analysis Services through the XMLA protocol. TOM is an extension of the Analysis Management Object client library. This exposes all the underlying meta-data like models, tables, and columns on which restriction can be enabled. Further, You would get an error when trying to access the dataset model in SQL Server Management Studio (SSMS). An error message will be generated if the current user does not have access to the OLS secured objects.
Limitations
Some of the limitations with object-level security are:
- Q&A Visual does not currently support OLS.
- Both RLS and OLS cannot be combined from different roles.
- Table-level security cannot be set if it breaks a relationship chain.
- Dynamic calculations are restricted if the security is enabled on that table or column to which the calculations refer.
Conclusion
It is a real challenge for organizations to have a strong restriction on what data is shown to whom. Microsoft is bringing in OLS that helps with taking the security and restriction of data to the next level by implementing granular restrictions on data. It is important for organizations to effectively implement and make use of OLS.
Learn more about Microsoft Power BI services offerings from Visual BI solutions here
