Secure filtering in Power BI Embedded

0
votes

Currently I have the following scenario. I have a report in Power BI which reads from a dataset which has data of all companies. In my ASP .NET MVC application the user will select the company for which to display the report and with Power BI Embedded the application filters the report by the ID of the company through the embed config defined in JS (filter parameters passed from server).

I am using app owns data approach where I have a master account and the embed token is generated for the master account. The user accessing the report does not have access rights to all companies and this is being handled server-side. With this approach however, the user can easily alter the embed config in JS and display the report for a company which he is not authorized to access.

I looked into row-level security and I found the following approach https://community.powerbi.com/t5/Developer/PowerBi-Embedded-API-Works-with-RLS/td-p/231064 where there exists a role for every company and the embed token is generated for that particular company. This would be an ideal approach but in my scenario the companies are not pre-defined and can be created any time. Therefore, I would need to create a role per company. This however cannot be achieved programmatically as Power BI does not provide means to automate role creation.

The only approach I can think of is to clone a report for each new company and create a dataset specific to that report which will only have the data for that particular company. Then the generated embed token will only be valid for that particular report.

Has anyone also experienced this dilemma? Any suggestions what I should do in such scenario?

1
azurepowerbipowerbi-embeddedrow-level-securityazure-security

1 Answers

2
votes

You still can use RLS, but without roles per company. Use USERPRINCIPALNAME() DAX function to find out which user is viewing the report. In the database make a table to specify which company can be seen by which user and add it to your model. Then use RLS to filter this table to only the row (or rows) where user is current one (here is where USERPRINCIPALNAME() comes into play), and let the relationship between this table and your data tables to filter out what should not be seen. This way there will be no JavaScript filters at all, so nothing can be changed by some malicious user.

See Using the username() or userprincipalname() DAX function.