[MUSIC].
>> Module 6, Part 2, Configure Data Permissions.
I'm Peter Myers, the course developer.
>> I'm Amit Shuster, product
manager of Power BI Embedded Analytics.
>> In this video, we are discussing
the final stage of development methodology for
embedding Power BI content with
a focus on configuring data permissions.
In this part two video,
we will describe how to pass
effective identity so your app
can effectively enforce the intended data permissions.
>> To enforce row-level security,
at least one effective identity object
must be passed when generating the embed token.
If you will try to generate
an embed token that has row-level security, and
you don't specify effective identity,
you won't to be able to render the report.
The object must include a username and a list of
one or more dataset IDs.
The objects can optionally include
at least one or more role assignments
and a custom data value.
Multiple effective identity objects
may be required to embed
a dashboard when tiles source
data from multiple datasets.
In this code example,
a single effective identity is instantiated.
You can see that we configure
the username as the CurrentUser:UserName.
The roles are set to AppUser.
You can also see the list of datasets
that this effective identity applies to.
>> In the previous video, we explained that
row-level security implementation will
depend on the dataset type.
Remember, there are four different dataset types that we
must consider when enforcing RLS in apps.
There are the internal- hosted models.
These include models hosted in
the Power BI service; and external-hosted models, which are
live connections to products like Azure Analysis
Services and SQL Server Analysis Services.
We will now describe how to pass
effective identity for all four dataset types,
starting with external- hosted models.
Azure Analysis Services:
A master user sccount or service principal
must have at least read permission on the model.
For service principal, you'll
pass the object ID as the username.
If no effective identity is passed, when
the embedding identity account
is an Analysis Services admin,
all users can view all model data.
However, when the embedding identity account is
not an Analysis Services admin, data
visibility will be limited by
roles assigned to that account.
Please note, it's a recommended practice
that the effective identity of
the master user account is passed
explicitly, even when row-level security
is not being enforced.
To enforce row-level security, pass effective identity.
The username must be a master user account,
UPN format, or a service principal with the object ID.
One or more roles must be defined in the model.
The roles must be passed to limit
data visibility by enforcing its rules.
The DAX USERNAME function will
always return the master user account.
The DAX CUSTOMDATA function
will return any string value
passed by effective identity
through the CustomData property.
For SQL Server Analysis Services,
the gateway data source credentials
must be an Analysis Services admin.
The embedding identity account must
be a gateway admin or have
ReadOverrideEffectiveIdentity
permissions on the gateway source.
A service principal can only be added by using the API.
If no effective identity is passed,
when the embedding identity account
is an Analysis Services admin,
all users will view all model data.
When the embedding identity account is
not an Analysis Services admin,
data visibility will be limited by
roles assigned to the master user account.
Note that it's a recommended practice that
the effective identity of the master user account is
passed explicitly, even when
row-level security is not being enforced.
To enforce row-level security
then pass effective identity,
the username must be a Windows account,
the username must have read permissions on the model.
One or more roles must be defined in the model,
and these roles can be passed to limit
data visibility by enforcing rules.
The username function will return
the username passed by effective identity,
and note that the CUSTOMDATA function is not supported.
For Power BI import models,
the embedding identity account already
has access to all the data in the model.
If no effective identity is passed,
then all users can view all model data.
To enforce row-level security,
then pass effective identity.
The username must be passed,
but does not need to be a real username.
One or more roles must be defined in the model.
These roles must be passed to limit
data visibility by enforcing rules.
The DAX USERNAME function will return
the username defined in the effective identity object.
The CUSTOMDATA function is not supported.
Note that the USERNAME function can
behave as the CUSTOMDATA
function because you can control
the value returned by the USERNAME function.
Now, for Power BI DirectQuery models.
The embedding identity account already
has access to all data in the model.
For data sources like Azure SQL,
they can be queried by the credentials
stored by the data source.
If no effective identity is passed,
all users can view all model data
according to the permissions of the data source account.
To enforce row-level security, pass effective identity.
The same facts as already presented
for import models apply.
Username must be passed,
but does not need to be a real username.
One or more roles must be defined, and they must be
passed to limit data visibility by enforcing the rules.
The DAX USERNAME function
returns the username value of
the effective identity and
the CUSTOMDATA function is not supported.
>> There are many good design practices to
consider when enforcing row-level security;
First, strive to enforce
data permissions through roles, not app logic.
Strive to reach scale by authoring secure master
reports, delivering
different data to different users.
Strive to define fewer models, with well-designed roles.
You should also strive to define
fewer roles leveraging dynamic filters.
When possible, create roles and rules on
dimension-type tables rather than the fact-type tables.
>> It's actually much more efficient.
Remember your dimension-type tables
are the things that you apply,
filters and grouping to.
Like your products, people, places, and concepts.
>> Verify that the model design, including
relationships and properties, are correctly configured.
>> This is really important, because
those model relationships propagate filters.
If these relationships aren't correct,
then you might have the wrong filters propagating and it
may not enforce the permissions you expect.
Six great points, but wait, there are more.
When using Power BI Desktop,
rigorously validate your role security,
ensure that the data source connections use
the same database user that will be
applied when uploaded to Power BI.
Test also scenarios with invalid values, like what
would happen if I passed in an incorrect username?
Would it still deliver values anyway?
Lastly, document roles,
their purpose and expected
username values for handover to the app developer.
>> Lastly, there are considerations
and limitations to bear in mind.
If a model does not define roles,
the GenerateToken request must not be passed
effective identity other than
the embedding identity account.
If a Power BI-hosted model defines roles,
effective identity must include at least one role.
Lastly, the list of the effective identity objects
defines multiple identity tokens for dashboard embedding.
For all other resources,
the list contains a single identity.
>> Great. Well, in the next video,
I'll demonstrate enhancing my app
by configuring data permissions.