ALON BARAM: [MUSIC]
Hello everyone, and welcome to
the Power BI Embedded Session in Microsoft Build.
My name is Alon Baram and for the last few years,
I'm the product manager for
Power BI Embedded product group in Microsoft.
Today, I'm going to present and
demonstrate our best practices for
deploying Power BI Embedded to production and
scaling it to many customer tenants.
On the agenda for today,
I'll provide a quick introduction to
Power BI Embedded Analytics and
the most common options to deploy
Power BI Embedded analytics to many customer tenants.
Then I'll demonstrate our new preferred option of
scaling Power BI Embedded
using Service principal profiles.
What is Power BI Embedded Analytics?
It's having Power BI Analytics infused in
your web application where you can
use and brand it as your own.
It allows you to personalize
user experience and visuals,
choose the best way to visualize your data,
and the best way to make it feel part of your user flow.
You can keep user information secured and use
row-level security to limit the user's access to data.
Lastly, it is purpose built
for developers by developers.
It includes Client APIs,
REST APIs and tools enabling
developers to automate processes
and minimize time to market.
Now, let's explore
the most common options to
deploy power BI Embedded Analytics for users.
Customers deploy Power BI for
their users depending on the profile and needs.
You can see the frame at the top of the slide,
Power BI authenticated users can consume analytics in
website portals or
SharePoint web path within their organizations.
At the bottom, you can see
the embedding options for
non Power BI authenticated users.
We call it embed for
your customers or white labeled embedding.
Embed for your customers makes use of
one entity to manage all authentications to Power BI.
User's authenticated to the web application with
any authentication method selected by the app owner.
In this option, Power BI offers
the ability to white labeled embedded content.
Our two main options for developers,
are the ones powered by client SDK.
Embed for your organization,
also known as user owns
data and embed for your customers,
known as app owns data or white labeled embedding.
This session will focus on embed for your customers,
which is mainly for external users or
the app owners who can use their own authentication.
End users do not need a Power BI license.
Authentication flow is non-interactive,
that is no user action
is needed for Power BI authentication.
Now I will describe the best practices for deploying
and managing multi-tenancy with Power BI Embedded.
What is multi-tenancy in Power BI Embedded?
It is the model determines how
each customer tenancy data is mapped and
managed within Power BI and application storage.
It defines a separation level
between customers known as tenants,
and it impacts scalability,
automation processes, and cost.
There are two main approaches for
multi-tenant deployment of Power BI Embedded.
Workspace based separation, where you create
a separate Power BI workspace per
a tenant and row level security based separation,
where the underlying data is used to control and
manage access to data per user or group.
In both methods, the app owner needs to
create development environment and
perform the following steps.
First, create a Service principal.
Then edit as a workspace member to an app workspace that
includes the analytics package
connected to Pre-prod Data source.
Going to production differences between the methods.
With RLS based separation,
you create the production workspace,
publish the Pre-prod content into this new workspace,
connect the production data
set to the customer's data source,
use RLS to filter and to separate between customers.
Lastly, assign the production
a workspace to capacity resource.
With workspace based separation,
you create a workspace per customer,
publish the Pre-prod content
into each new customer's workspace,
then update each customer's data set to connect to
the data source and assign one or more capacities.
Workspace based separation is
the recommended method as it
provides better data separation,
better scalability, and it's more cost effective.
I will describe now how is content managed and
what is the user flow in a multi-tenancy environment.
In this example, I'm using the preferred method,
which is workspace based separation.
The end users that connect to
your web application may be from different customers.
Let's call them tenants.
They authenticate to your app,
where you have your business logic.
By using mapping strategy
on the back-end side of your application,
you can map each user to the relevant parameters.
For example, which report and
data set the user should have access to,
which workspace and
Service principal profile are associated with
users tenant and what RLS rule
should be enforced for the user.
Then the application uses these parameters to get
the right embed token for
the users and pass it to the user's browser.
The browser uses the Embed token
to communicate with Power BI service directly.
For multi-tenant application design
using world's best operation,
we used to offer three options and recently we
have launched the fourth one
using Service principal profile.
I will review the three briefly
to emphasize the strength of the fourth.
The first solution we
offered was single Service principal.
The biggest downside is that you can
only go up to 1000 workspaces,
but you're also going to slow down
gradually as you reach hundreds of workspaces.
Because Service principal is owner of
data source credentials across all customer tenants,
you are far from optimal
data source credentials isolation.
The good aspect of this option is
the one time creation of
Azure AD application for Service principal.
Service principal pooling was another option.
It was the most popular for
our larger Power BI Embedded customers.
Scalability is not limited,
but performance and isolation issues are
still not solved and you still need to go
back to IT occasionally to create
new Azure AD applications
as number of customer tenants increases.
One service principal per customer tenant used to
be the recommended option as it served scalability,
performance, and isolation issues.
But there is a need to continuously create
new Azure AD applications and for large organizations,
this could be a bureaucratical nightmare.
Service principal profile per
customer tenant is our new and
recommended option as it
solves all the issues I've mentioned before.
Plus, it requires only one time creation
of Azure AD Application for service principal.
What is a Service principal profile?
Service principal profiles are local
Power BI accounts created by a Service principal.
They are created by an API and you can
create as many as you need by
a single Service principal.
They are unknown to Azure AD,
it's totally a Power BI thing.
The ISV application; Service principal,
creates a different Power BI profile for each customer.
When a customer visits the ISV application,
the application uses
the corresponding profile to generate and
embed token that will be used to
render a report in the browser.
Using service principal profiles enables
the ISV application to host
multiple customers on a single Power BI tenant.
Each profile represents one customer in Power BI.
In other words, each profile creates and
manages Power BI content
for one specific customer's data.
Looking from a security model point of view,
service principal profile is
a first-class security principle
in Power BI authorization system.
It can be entered as a workspace member,
execute Power BI,
REST API calls to create workspaces,
data sets and set data source credentials,
and it can generate embed tokens.
As you can see in the Solutions comparison table,
it combines the best of all other options,
low Azure AD Overhead,
complete data source isolation,
and optimize Power BI API performance.
I will drill down a bit to creation and
management of service principal profiles.
The first thing you need to do is to enable
a new Power BI tenant feature switch called
Allow service principals to create and use profile.
[MUSIC]
Your Power BI tenant admin
can do it in the Power BI admin portal,
tenant settings, developer settings.
As usual with the workspace based separation,
you also need to make sure that
the following two feature switches are
enabled as well: Allow
service principals to use Power BI APIs and Create
workspaces to allow our service principal profiles
to create workspaces for customer tenants.
[MUSIC]
Now here is the profiles API.
Our engineering team have introduced a new profiles API
which is used to create and
manage service principal profiles.
You can find a recommendation for
the profiles API at the presented URL.
The profile is basically a name with
a grid on it and you can create,
delete, get, and update it.
How do you create a new customer tenant
using a Service principal profile?
The first step is to execute an API call
to create a new service principal profile
with its display name.
That first call is made under
the identity of the parent service principal,
but this is the only one.
All the remaining Power BI REST API
calls shown in the following list could be
made under the identity of
the Service Principal Profile
that has just been created.
Create workspace, assign workspace to capacity,
import PBIX, update data set parameters,
set credentials, and start refresh.
That's basically what you need to
do to create a new customer tenant,
and you can do it for
hundreds of thousands customer tenants
using only one service principal.
I'll demonstrate. Now the app owns
data multi-tenant application
developed by third partisan.
A principal PM in
the Power BI customer advisory team and an
industry leading expert on
developing with Power BI embedded analytics.
The application demonstrates how to manage
a multi-tenant environment for Power BI
embedded using service principal profiles.
You can find the link to the resources of this app in
the Power BI Embedded Analytics Resources slide
at the end of the session deck.
[MUSIC]
The design strategy used by
app-owns-data multi-tenant application optimizes
calls to Power BI REST API while also providing
complete data set and data source credential
isolation at the customer tenant level.
The design of the app-owns-data multi-tenant application
makes it possible to scale
upwards to manage an environment with up to and
beyond hundreds of thousand customer tenants.
The app-owns-data multi-tenant application provides
a form which allows
the user to create a new customer tenant.
When using the application,
you can enter the tenant name for
a new customer and
the details of the customer's database.
Let's call the first one Aviv1.
When you click the Create New Tenant button,
the application responds by
executing code which begins by
creating a new service principal profile
using the same name as the third name.
After creating the service principal profile,
the application then switches context and begins calling
the Power BI REST API using
that profile identity to create
the new workspace and populate it with content.
This application design maintains
a one-to-one relationship between
service principal profiles and customer turned
workspaces which is what we recommend as best practice.
Now I click the Onboard New Tenant button
again to create a second customer tenant.
Let's call it David1.
Select "ContosoSales" from the drop-down list for
database name and create new tenants.
You can see now that I have two customer tenants.
When I click the Profiles link,
I can examine each of
the profiles that have been created.
When I click on the Power BI Profiles link,
the application calls the Get Profiles operation of
the Power BI REST API to retrieve
all the profiles that have been
created by the applications service principal.
Now that I've created two customer tenants,
I can access their content by navigating
back to the Tenants page and clicking on
the View button for a specific tenant on
the Tenants page to drill into the Tenant detail page.
The tenant detail page displays
Power BI workspace detail including its members,
data sets, and reports.
The app-owns-data multi-tenant application
can also embed reports.
On the Tenants page I click
the Embed button for a Aviv1 tenant to navigate
to the Embed page where I can see
a page with an embedded report for Aviv1 tenant.
When I click the Embed button for David1 tenant,
I can see that the application is able to
embed a report from any customer tenant.
When a user navigates to
the Embed page for a customer tenant,
the application must determine which
service principal profile was
used to create the target workspace.
The application performs a look up in
the app-owns-data multi-tenant DB
Database to determine which
service principal profile ID
is associated with the target workspace.
The application is then able to
query for workspace artifacts and
to generate the embed token
using that service principal provide's identity.
If you're curious about what's been created in Power BI,
you can see it by navigating to
the Power BI service portal,
and you should be able to see and navigate to any of
the Power BI workspaces that have been created by
the app-own-data multi-tenant applications.
When I navigate to workspace
Aviv1 and I click on the Workspace Access pane,
I can see two members including my user account;
Sabri and service principal profile.
When I drill into
the Setting page for the data set name Sales,
I can verify that
the Sales data set has been configured by
a service principal profile which is evidenced
by the Service Principal
Profile Object ID as you can see.
[MUSIC]
With that we conclude
the app-owns-data multi-tenant application demo,
and I hope it has allowed you to get an impression of
the new multi-tenancy design option based on
service principal profiles we've
introduced few weeks ago.
To conclude this session,
we're providing you with links to our developer samples,
documented APIs, Power BI embedded playground,
embed setup tool, and more.
As always, we encourage
you to provide feedback at Power BI IDs.
See the link at the bottom of the page.
If you ask yourself what is
the best way to get updates and help?
Power BI developers periodic blog posts
present all the new features and updates.
Stack Overflow will get your help from
the developers community and in
their own words for developers by developers.
That's all folks.
I would like to thank you for watching this session.
Feel free to send me questions,
I will try to respond them all. Ciao.