Archive for month: October, 2015

UPDATE: An updated sample is included in the Chapter 12 source code of my “Applied Power BI” book.

One of the biggest Power BI strengths is its open architecture. In addition to opening the visualization framework, Power BI introduced REST APIs that let developers embed dashboard tiles in custom web applications (embedded reports will probably follow soon). Microsoft provided a sample application (Integrate-a-tile-into-an-app) on GitHub to demonstrate how dashboard tile embedding works. This application navigates the user to an authentication UI where the user signs it to Power BI before the application can access the user content. However, there are plenty of embedded reporting scenarios where this isn’t desirable. For example, you might have a web application that already authenticates users with Forms Authentication and you don’t want to ask the user to log in to Power BI again. Instead, you might want to pass the identity of the authenticated user to Power BI. In the more advanced (but increasingly common) scenario, you would want Power BI to pass the user identity all the way to an on premises Analysis Services model so that data security works.

The bad news is that currently Power BI doesn’t support custom security. Custom security is on the roadmap but currently you can’t pass application users to Power BI. This isn’t as bad as it sounds. For example, if you have a limited number of users or external customers, you can register them in Power BI so that you know their Power BI usernames and passwords. For example, if my company does business with Acme1 and Acme2, I could register acme1@prologika.com and acme2@prologika.com with PowerBI. Then, once the acme1 user authenticates with my web application and request a dashboard, I can authenticate the user with acme1@prologika.com to Power BI.

The good news is that Power BI supports OAuth2 for security. OAuth2 is a very flexible security mechanism and it supports different flows via the grant_type parameter. One of the flows that it supports is the grant_type=password flow that allows you to avoid the Power BI authentication UI step if you know the user credentials. This is conceptually similar to how Basic Authentication works. The OAuth2 grant_type=password scenario is also referred to as two-leg authentication (the three-leg authentication is when the Authentication UI is involved).

To demonstrate this, I’ve made changes to the Microsoft sample app and uploaded the modified sample (attached to this blog). Configure it in Visual Studio as follows:

1. In the application settings, change the ClientSecret, ClientID, UserName, and Password to match your setup. You obtain ClientID and ClientSecret when you register the application with Azure AD. The username and password must match the credentials of a registered Power BI user.
2. In the application Build tab, make sure that the NOLOGIN conditional symbol exists.
3. Right-click on the project and then click Manage NuGet packages. Download and install all referenced packages as they are not packaged with the sample to reduce size.
4. Run the application. The “Sign in to Power BI” button should be disabled. When you click Get Dashboards, the app should be able to retrieve the dashboards on behalf of the Power BI user. From this point on, the app works as per the original sample. Again, the big difference is that the Authentication UI is not shown because you don’t need to collect the user credential.

Special thanks to the Power BI Team and Rui Quintino by DevScope for sharing insights. For more information about how APIs for embedded dashboard tiles work, read the “Power BI API updates roundup” blog by Lukasz Pawlowski.

In summary, the sample demonstrates how you can use OAuth2 two-leg flow to avoid authenticating the user twice and redirecting to the Power BI authentication dialog. As a disclaimer, this is not a production-ready sample (there are hardcoded links, no error handling, no refresh token flow, etc.).