>> [MUSIC] Module 3, Configure Permissions.
Hello I'm Peter Myers, the course developer.
>> I'm Noam a product manager on
the Power BI Embedded team.
>> In this video, we'll describe
token types and how to acquire an access token.
>> Access is granted using two different types of tokens:
There's the Azure AD token
and there's also an embed token.
Let me now describe each token type.
The Azure Active Directory token,
also known as an Azure AD token,
must be acquired to access Power BI content.
Your Azure AD token will be acquired
differently depending on your embedding scenario.
If you're embedding for your organization,
it will be acquired from an app user.
If you're embedding for your customers,
it will be acquired using a dedicated Azure identity.
The Azure AD token contains
claims to identify granted permissions to
the Power BI REST API
to control which content will be presented.
A valid Azure AD token must be
present in all API operations.
Consider this as your key for embedding.
>> The second type of token is the embed token,
and it's a very different concept.
An embed token must be acquired to embed Power BI content
and query data when using the
"for your customer" scenario.
It is generated by using the REST API.
It contains claims to access
specific Power BI content and other facts.
>> All Power BI REST API calls
require a valid Azure AD token.
Keep in mind that by default,
this expires after an hour.
The authentication flow will
differ based on the scenario,
whether you're embedding for your organization
or for your customers.
>> Here are some important facts you need to know when
developing for your organization scenario:
App users have Power BI
accounts and appropriate licenses.
The app users account is
used to authenticate with Power BI.
The app users identity is used to
access content and query datasets.
It's supported for any Power BI content
the app user can view and in licensing,
A SKUs are not supported.
Note that we'll be covering licensing in
a later video in this series.
Now, let's see how the authentication flow works.
>> Your app users will
authenticate with Azure AD to acquire
their access token in an interactive authentication flow.
Once the Azure AD token is acquired,
the app will cache this access token,
and it will use it to embed
any Power BI content that
the app user has permission to view.
>> Now, what's a good example of
using the "for your organization" scenario?
>> A good example of "for your organization" is embedding
for Teams and SharePoint, but not only.
You should consider using the "for
your organization" scenario when you
want a custom experience instead of
the Power BI service experience.
You should also consider it
if you're looking to integrate Power BI content
with other content or if your data
access permissions need to be those of the app user.
Lastly, you should consider using the "for
your organization" scenario if you're looking to
customize audit logging of your content.
>> Let's now describe important facts when
developing for the "for you customer" scenario.
When using your app, the app user does not
require a Power BI account or license;
any authentication method can be used by the app.
A dedicated Azure AD identity
is used to authenticate with Power BI,
and it can be either a service principal
or master user account.
An embed token is required to embed
Power BI content when using an effective identity.
It requires specific licensing:
A or P SKUs.
Again, we'll be covering licensing in
a later video of this series.
Let's now talk a bit more about the embed token.
>> The embed token represents several facts:
It represents which Power BI content can
be accessed and also the access level.
Whether it can only be viewed or also edited (for reports).
Optionally, effective identities can be used
to access content and also query the data.
The embed token can also represent
the target workspace for "save as" of edited reports.
Keep in mind that the embed token will
expire when the access token expires.
However, your app can be developed to silently
regenerate the embed token when it expires.
>> Great. Now, let's see how
the authentication flow works in this scenario.
>> In this scenario, your app user
authenticates to the app with any authentication method.
The app uses a dedicated Azure AD identity
to acquire an access token for the user.
This is done through
a non-interactive authentication flow.
Once the access token is acquired,
the app will cache it and use
it to generate an embed token,
which is required to embed Power BI content.
>> Remember in this course,
we focus mainly on this scenario.
Next, let's talk about
the two types of embedding identities:
They are service principal and master user.
>> An Azure service principal is
a security identity used by apps.
It can authenticate using an app secret or a certificate.
When used to access Power BI content,
the app will use the service principal
to acquire an access token.
The service principal must be an admin or member of
the workspace that contains the content to be embedded.
Keep in mind that the service principal
does not need a Power BI Pro license.
Lastly, a Power BI tenant admin
must first enable the use of
service principals and register
service principal security groups.
>> Let's see how that's done.
Here in the Admin Portal,
under Tenant Settings and
under the Developer Settings group,
a Power BI admin can enable the service principal
and also specify the security groups
that can work with the service principal.
Let's now talk about the second identity type,
the master user account.
>> The master user is a regular Azure AD user.
When used to access Power BI content,
the app will use the user account
to acquire an access token.
The master user must belong to the Admin or
Member roles of the workspace that
contains the content to be embedded.
In this case, the master user must have
either a Power BI Pro or
Power BI Premium Per User (PPU) license.
>> That's a lot of information to take in.
Let's now review what we've introduced by comparing
the capabilities of both identity types.
>> For the service principal, that
Azure AD object type will be a service principal.
The credentials will be managed in a secret
or certificate rotation management.
The Power BI tenant settings must be enabled and
a service principal must belong
to a declared security group.
As further API usage,
you can use all of the APIs except for
some admin operations and some dataflows operations.
It's not possible to sign into the Power BI service with
a service principal and
a Power BI Pro license is not required.
This is the Azure AD recommendation.
>> Now, for the master user,
it's just an Azure AD user
and from a credential management point of view,
it's up to you to apply frequent password changes.
There are no Power BI tenant settings and
the master user has access to all API operations.
It is possible to sign in using the master user to
the Power BI service and note that
a Power BI Pro license will be required.
However, this is not an Azure AD recommendation.
Which identity should you use?
We have prepared some guidance to help you.
>> Generally, the service principal
is a good choice for production.
The service principal is the
recommended approach by Azure AD.
It supports better automation and scale,
and there's less management overhead.
However, it does require
Azure AD and Power BI admin rights to set up and manage.
>> The master user is a good choice
for development or test environments.
It's easy to set up.
It can be used to sign in to
the Power BI service to help troubleshoot issues.
However, it requires a Power BI Pro license.
In the next video, I'll
demonstrate how to configure permissions.