Security (RLS)
RLS (Row-Level Security) in Power BI can be used to restrict data access for specific users. Filters restrict data access at the row level, and you can define filters in roles.
RLS allows you to:
Define data loading filters based on the user viewing the report
Create multiple data filterings in a single report
Restriction by user profile
Restriction by role (job title/department)
One of the advantages of RLS is having a single report and distributing it to multiple users or clients, without having to create a report with filtered data for each user profile, reducing the maintenance of these reports, since a single report would filter the results displayed according to the person viewing it.
In Power Embedded, we support both RLS (Row-Level Security) and OLS (Object-Level Security).
RLS/OLS is configured ONLY in Power Embedded, no longer in the Power BI service.
If it is necessary for some people to continue accessing the report in the Power BI service, you will need to configure it in Power BI as well.
Below is some information to help with understanding.
When the report has one or more RLS rules, it is mandatory to associate it with the user viewing the report, either using static or dynamic RLS, otherwise they will not be able to view the reports, and a message like this will be displayed:
Unlike the Power BI service, where administrator users are not affected by RLS, in Power Embedded, ALL users are affected by RLS.
If an administrator user is not in any security rule, they will receive the error message above. If this user needs to view all data, create a security rule without any filter and associate the user with that security rule.
How to manage security rules in Power Embedded
To associate a user with an RLS or OLS rule, you have 3 ways to configure this:
On the Datasets page, search for the dataset you want to manage the RLS rules for, click the Actions button, and then click the Security item. \
Static Security
For companies that need or would like to create multiple security rules and associate users with the rules, without the need to have a table in the model with users and permissions, there is static security, which is simpler to configure, but has worse performance and is harder to manage permissions.
In this format, you will see the list of roles that exist in the model and can associate users or groups that will be filtered by that rule, by clicking the actions button.
Here is a screenshot of the rules created in Power BI Desktop. There are two rules created: 'Foods' and 'Beverages'. This means that if a user is assigned to the Foods rule, they can only view data related to foods.
After publishing the report and accessing "Actions" > "Security", Power Embedded automatically identifies the created rules and loads the list with these rules.
You can then assign these rules to users as needed.
If the list of security rules is not being displayed on the security screen, even after clicking the "Reload roles list" button, it is probably because the report's workspace is in a PRO capacity instead of a dedicated capacity (Fabric, Power BI Embedded, or Power BI Premium).
When user "marcos" accesses the report, they will only see information related to foods.
Dynamic Security
With Dynamic Security, you can define one or more roles and they will be automatically applied to all users who access the report. This is the best practice recommendation for better rule management and performance.
In this format, the role/function created in Power BI Desktop will receive the email of the user accessing the report (using the USERNAME() or USERPRINCIPALNAME() functions) and will be responsible for performing filters using this email, based on the created rules.
In this approach to automatically applying filters per user, it is necessary to maintain in your model a table with users and permissions according to the RLS or OLS rule.
The table below illustrates a model containing the email information of the managers of a given report.
Relationship between the tables, meaning your table will be linked to a fact table that contains the information.
After publishing this report, the rule becomes visible in the portal — simply select it and the rule will be applied. Unlike static security, here you do not assign a user to the rule; you simply click on the rule you want to apply.
Report without the existing rule:
Report with an existing RLS rule in the model using dynamic RLS:
The RLS rule is applied using the UserPrincipalName() function to identify which user is logged in and perform the filter on other tables as well, meaning the user can only view information relevant to them.
Priority of static and dynamic RLS
To correctly configure RLS rules in some scenarios, it may be necessary to use both static and dynamic RLS at the same time.
How Power Embedded prioritizes these rules:
Checks if the user viewing the report is associated with any static RLS rule. If so, sends that rule and ends the validation.
Checks if the user viewing the report belongs to any group that is associated with any static RLS rule. If so, sends that rule and ends the validation.
Checks if any dynamic RLS rule is selected. If so, sends that rule and ends the validation.
None of the previous conditions were met, so no RLS rule will be sent and there will probably be an RLS error when trying to open the report.
RLS with DirectQuery in Power BI
If you encounter the error below when trying to access the report, it is very likely that the table containing the RLS rule is using the DirectQuery connection.
DirectQuery is widely used to access real-time data. However, it is important to note that Row-Level Security (RLS) rules do not directly apply to tables connected via Direct Query in Power BI.
This happens because the configuration of these rules, when using DirectQuery, must be done at the database level, not in Power BI.
Therefore, it is important to change the table connection to Import or Dual mode, if it is necessary to apply these rules.
To change the table connection, follow the steps below:
Open Power BI Desktop.
Go to "Model View".
Select the table that has RLS rules and is connected via DirectQuery.
Access the "Advanced" menu, as shown in the image.
Change the storage mode to "Import" or "Dual".
After following the previous steps, a warning like the one shown in the image will appear on the screen. Just click "OK" and proceed. After completing this process, simply publish the report again.
You will now be able to see your information.
Limitations when using RLS in Embedded reports
When using RLS (Row-Level Security) in embedded reports, it is important to consider some limitations defined by the Embed Token generation API.
According to Microsoft's official documentation, the roles parameter, used during embed token generation, is responsible for informing which RLS roles should be applied to the user accessing the report.
According to the documentation:
An identity can contain up to 50 RLS roles
A role name can contain any character, except
,A role name cannot exceed 50 characters
This means that when embedding reports that use RLS, the role name defined in the model cannot have more than 50 characters, as this value is sent at the moment of access token generation. The 50-character limit applies only to the role name, not to the logic or expression used in the security rule.
Therefore, when creating security roles in Power BI Desktop, it is recommended to keep names short and objective, ensuring the length does not exceed 50 characters, to avoid issues when generating the embed token.
Microsoft's official documentation: Embed Token - Permissions
Atualizado