Power BI Premium is built to meet the most demanding compliance, scale, and security requirements for enabling a data culture within your organization. Our recent announcements for large model support and XMLA endpoints enable fast query performance and solutions for your largest enterprise datasets; further empowering your teams to easily leverage large single source of truth datasets for intelligent decision-making. In this new environment, securing your datasets is not only prudent, but critical to successfully standardize BI within your enterprise.
We‘re excited to announce that object level security (OLS) is now available for public preview in Power BI Premium, Premium per User and Pro! Object-level security, along with row-level security (RLS) enables enhanced enterprise grade security on your reports and datasets ensuring only users with the requisite permission have access to view and interact with sensitive data.
What is object-level security?
Object-level security (OLS) enables model authors to secure specific tables or columns from report viewers. From a viewer standpoint, the table or column simply does not exist. With object-level security, you can not only restrict access to data, but also sensitive object names. This prevents users from discovering sensitive data such as employee or insider financial records. All metadata for reports that are opened in the Power BI service that include an OLS object is secured in the caching layer.
For context on how this improves your model security, let’s contrast with row-level security or perspectives. Row-level security (RLS) is a feature that enables you to protect data by assigning views to roles. Defining DAX filters restricts row data access for roles that do not have the requisite permission. However, users can view the specific metadata objects in the model. With perspectives you can also hide tables and columns from users, but it is not a security feature. Like RLS, hiding tables and columns using perspectives does not prevent users from accessing them via DAX. Users could also simply change the connection string to use a different perspective or access a full model view. Row level security, on the other hand, is a security feature; yet, RLS does not completely hide the model metadata. In contrast, object-level security does, it not only hides tables and columns, but also secures them. Your secured tables and columns are obscured in the field list when using reporting tools like Excel or Power BI. A user without permissions cannot access secured metadata objects via DAX or any other method. To viewers that don’t have the requisite permission, the secured tables or columns simply do not exist.
To enable object-level security
Like row-level security, object-level security is defined within model roles. Currently OLS definitions are not created natively in Power BI Desktop, but external tools such as Tabular Editor can set OLS rules on Power BI Desktop datasets or through the XMLA endpoint in the service using TMSL or TOM. In this post, we’ll use Tabular Editor, an external tool to manage tabular models and define OLS rules for a dataset.
How to configure object-level security by using Tabular Editor
In Power BI Desktop, create the roles that will define your OLS rules. Click on the Manage Roles button in the Modeling tab on the ribbon.
On the External Tools ribbon, click Tabular Editor. If you don’t see the Tabular Editor button, install the program from tabulareditor.github.io. When open, Tabular Editor will automatically connect to your model.
In the model view, select the drop-down under Roles. The roles created in the previous step will appear.
Select the role you wish to enable an OLS definition and edit the rule to None or Read.
After you’ve defined object-level security for the roles, save your changes.
In Power BI Desktop, publish your dataset to the Power BI service. In the Power BI service, navigate to the Security page by selecting the more options menu on the dataset. Then assign the members or groups to their appropriate roles, and then click Save.
At this point, the object level security rules are defined. Users who do not have the requisite permission will receive a message that the field does not exist for all report visuals using the field.
OLS with the XMLA endpoint in Power BI Premium
To query the dataset directly or set up OLS rules with TOM or TMSL, first enable the XMLA endpoint, so you can use tools like SQL Server Management Studio (SSMS).
When querying directly, if the current user doesn’t have access to OLS secured objects, the error message returned will not disclose the existence of OLS secured objects.
To learn more, see Object-level security in Analysis Services tabular models.