Power BI Blog: Row-Level Security (RLS) – Part 2

One of the key features that distinguishes Power BI from other Business Intelligence (BI) solutions is its ability to provide row-level security (RLS), which is protection based upon each row of a data table.  Instead of creating a report for each of the access profiles, you can create a single report linked to different access profiles. 

Last week, we looked at how to set up static RLS in Power BI Desktop, by creating roles.

We checked the role worked as expected using the ‘View as’ facility in the Security section of the Modeling (sic) tab.

There is no security in the PBIX file; you can see the entire dataset.  There is no way that you may have any sort of security with Power BI Desktop files and roles may only be created or modified inside Power BI Desktop. 

This week, we continue by looking at the impact in Power BI Service.

Manage Your Model’s Security – Static

In Power BI Service, members of the same workspace have access to datasets, RLS will not restrict this data access.  With our dataset saved and published to a workspace, we can use the Power BI Service to share it with the Australian managers.  Within the Power BI Service, under the workspace where you have saved your report, go to ‘Datasets + dataflows’ and click on the ellipses (‘…’) (if you mouse over it will display ‘More options’) and select Security.

Managing Members

It is vital to note that if you share your report (with row-level security applied) with any member prior to assigning a role to them on Power BI Service, the user will be allowed to open the report, but all visuals will display the warning 'This Visual includes restricted data':

In the ‘Row-level Security’ page you may add members to a role that you have defined in Power BI Desktop, as well as review who is limited in this capacity. 

By entering the user's email address in the 'People or groups who belong to this role' box, you may add a member to the role in the Power BI Service.  If we need to remove a member, either due to wrong registration, change of department or due to termination of contract, for example, members can be removed by clicking the ‘X’ next to their name. 

Please note that by adding members in this manner, you are not sharing the report with them.  Instead, you are assigning security, i.e. notifying Power BI that these individuals are part of this created role. 

Validating Roles within the Power BI Service

In Power BI Desktop, we checked what a role could see by using ‘View as’.  You may also validate roles within Power BI Service.  This can be done by hovering your mouse over the role and clicking in the ellipsis (‘More options’) and then selecting ‘Test as role’.

This will forward you to the report that was published from Power BI Desktop using this dataset.  The role that is currently being used is displayed in the page header and the entire report will be filtered to display only the data that the specified role may view.

Clicking ‘Back to Row-Level Security’ will return to our RLS settings. 

Considerations and Limitations       

Amongst the concerns and constraints of using row-level security, you should note:

• you must recreate any roles and rules that you previously created in Power BI Service in Power BI Desktop
• RLS may only be applied to datasets created using Power BI Desktop.   If you wish to enable RLS for Excel datasets, you must first convert them into Power BI Desktop (PBIX) files
• you will be unable to setup RLS within the Power BI Service if you use a live connection.  This is defined in the on-premises Analysis Services model. 

Next time, we will move on to setting up and using dynamic RLS.

Check back next week for more Power BI tips and tricks!