Believe it or not there is a way to use Power BI without signing up or having an account. With an embedded application, you can use one Power BI ID and have all users use this account to log in. Now before you judge this is concept as a horrible security idea, keep on reading as you may change your mind. In this embedded application all users to login using a unique id and password and restrict the data seen in Power BI data based upon that id. How do you accomplish this seemingly incongruent task and why would you ever do such a thing? Well it turns out there is a logical reason for wanting to implement a Power BI application this way.
Creating a way to Securely Access Power BI Data for Customers
There are many companies which would like to provide Power BI reports which would allow customers to interactively work with their data, but they don’t want to create Power BI accounts for customers as that can be a lot of work from an administrative standpoint. For the same reason, these customers are not added to the corporate network which means they are not added Active Directory. For example, if Desert Isle SQL contracts with Acme Corporation to create a custom conference display, Acme might want to show me a report showing when the components were purchased, when they were modified and when the order is in process and when the order is completed. How do I show a Power BI report containing information? From an application design perspective data from all of the customers should be stored in the same place and Desert Isle SQL should only see their orders when logging in to Acme’s site. Here is the workflow that I want to implement.
Passing Login information to Power BI
When creating an embedded application, connecting requires a connection string. It is possible to pass additional information to the connection string buy modifying the gateway to use effective identity and then pass the role information you want to use. There are two configuration steps you need to complete to make this work. The Power BI gateway needs to be configured to use CustomData through the Map User name screen. Also SSAS needs to be configured to use Roles as the role will restrict the data that users can access. The CustomData can contain a comma delimited list of values, which can include the data I need to have to access the role. In the DAC for the role, the CUSTOMDATA field as performs as if it was a table. The DAX in the role would provide permissions based on the value of that table DimTerritory[TerritoryName] = IF(CUSTOMDATA() = “username”.“territory” . This will restrict the data that a customer can see based on the territory they have assigned. The Id can then be used to implement Row level security in Power BI with either the embedded data model or with Analysis Services Tabular. By using this method, you have the ability to restrict the data for each user and use one Power BI account all at the same time.
Costs for Implementation Multi-User Power BI Systems
Unfortunately, this solution means that you are going to be purchasing the embedded version of Power BI as this functionality is not covered with a Pro License. Embedded applications require that you purchase an embedded license or have a premium account. The pricing for embedded has changed quite a bit from 2017 when it was introduced. Pricing is all about capacity, unless you use a Premium account.
Power BI can be implemented in a number of different ways, and this implementation is one that you may see more of in the future. There are a lot of different things that you can implement Power BI and it is hard to keep up with all of the changes. If you are interested in learning more about some of Advanced Power BI topics, join me in person in Boston for a full day of Advanced Power BI Training on Friday, September 21. I look forward to meeting you here or anywhere else we might meet up.
Yours Always
Ginger Grant
Data aficionado et SQL Raconteur