Skip to content

Latest commit

 

History

History
158 lines (91 loc) · 12.2 KB

service-admin-row-level-security.md

File metadata and controls

158 lines (91 loc) · 12.2 KB
Raw
title description author ms.author ms.reviewer ms.service ms.subservice ms.topic ms.date ms.custom LocalizationGroup ms.collection no-loc
Row-level security (RLS) with Power BI
How to configure row-level security for imported semantic models, and DirectQuery, within the Power BI service.
mberdugo
monaberdugo
powerbi
powerbi-admin
how-to
04/24/2024
Administration
ce-skilling-ai-copilot
Copilot

Row-level security (RLS) with Power BI

Row-level security (RLS) with Power BI can be used to restrict data access for given users. Filters restrict data access at the row level, and you can define filters within roles. In the Power BI service, users with access to a workspace have access to semantic models in that workspace. RLS only restricts data access for users with Viewer permissions. It doesn't apply to Admins, Members, or Contributors.

You can configure RLS for data models imported into Power BI with Power BI. You can also configure RLS on semantic models that are using DirectQuery, such as SQL Server. For Analysis Services or Azure Analysis Services lives connections, you configure row-level security in the model, not in Power BI. The security option doesn't show up for live connection semantic models.

[!INCLUDE include-short-name]

By default, row-level security filtering uses single-directional filters, whether the relationships are set to single direction or bi-directional. You can manually enable bi-directional cross-filtering with row-level security by selecting the relationship and checking the Apply security filter in both directions checkbox. Note that if a table takes part in multiple bi-directional relationships you can only select this option for one of those relationships. Select this option when you've also implemented dynamic row-level security at the server level, where row-level security is based on username or login ID.

For more information, see Bidirectional cross-filtering using DirectQuery in Power BI and the Securing the Tabular BI Semantic Model technical article.

:::image type="content" source="media/service-admin-row-level-security/row-level-security-apply-security-filter.png" alt-text="Screenshot of selected apply security filter checkbox.":::

Define roles and rules in Power BI using enhanced row-level security editor (Preview)

You can quickly and easily define row-level security roles and filters within Power BI using the enhanced row-level security editor. With this editor, you can toggle between using the default drop-down interface and a DAX interface. When you publish to Power BI, you also publish the role definitions.

To define security roles using the enhanced row-level security editor:

  1. In Power BI Desktop, enable the preview by going to Files > Options and Settings > Options > Preview features and turn on “Enhanced row-level security editor”. Alternatively you can use this editor in the Service by editing your data model in the Power BI service.

  2. Import data into your Power BI semantic model, or configure a DirectQuery connection.

  3. From the ribbon, select Manage roles.

    :::image type="content" source="media/service-admin-row-level-security/manage-roles-ribbon-button.png" alt-text="Screenshot of the Manage roles button in the Desktop ribbon.":::

  4. From the Manage roles window, select New to create a new role.

    :::image type="content" source="media/service-admin-row-level-security/enhanced-row-level-security-new-role.png" alt-text="Screenshot of creating a new role in the enhanced row-level security editor.":::

  5. Under Roles, provide a name for the role and select enter.

    :::image type="content" source="media/service-admin-row-level-security/enhanced-row-level-security-rename-role.png" alt-text="Screenshot of renaming a role in the enhanced row-level security editor.":::

  6. Under Select tables, select the table you want to apply a row-level security filter to.

  7. Under Filter data, use the default editor to define your roles. The expressions created return a true or false value.

    :::image type="content" source="media/service-admin-row-level-security/enhanced-row-level-security-example-default-editor.png" alt-text="Screenshot of an example of using the default editor in the enhanced row-level security editor.":::

    [!NOTE] Not all row-level security filters supported in Power BI can be defined using the default editor. Limitations include expressions that today can only be defined using DAX including dynamic rules such as username() or userprincipalname(). To define roles using these filters switch to use the DAX editor.

  8. Optionally select Switch to DAX editor to switch to using the DAX editor to define your role. You can switch back to the default editor by selecting Switch to default editor. All changes made in either editor interface persist when switching interfaces when possible.

    :::image type="content" source="media/service-admin-row-level-security/enhanced-row-level-security-example-dax-editor.png" alt-text="Screenshot of an example of using the DAX editor in the enhanced row-level security editor.":::

    When defining a role using the DAX editor that can't be defined in the default editor, if you attempt to switch to the default editor you'll be prompted with a warning that switching editors may result in some information being lost. To keep this information, select Cancel and continue only editing this role in the DAX editor.

    :::image type="content" source="media/service-admin-row-level-security/enhanced-row-level-security-parse-warning-dialog.png" alt-text="Screenshot of an example error dialog when switching from the DAX to default editor in enhanced row-level security editor.":::

  9. Select Save

[!INCLUDE include-short-name]

Manage security on your model

To manage security on your semantic model, open the workspace where you saved your semantic model in the Power BI service and do the following steps:

  1. In the Power BI service, select the More options menu for a semantic model. This menu appears when you hover on a semantic model name, whether you select it from the navigation menu or the workspace page.

    :::image type="content" source="media/service-admin-row-level-security/dataset-left-nav-more-options.png" alt-text="Screenshot showing the More options menu in the workspace.":::

    :::image type="content" source="media/service-admin-row-level-security/dataset-canvas-more-options.png" alt-text="Screenshot showing the More options menu in navigation menu.":::

  2. Select Security.

    :::image type="content" source="media/service-admin-row-level-security/dataset-more-options-menu.png" alt-text="Screenshot showing the More options menu with Security selected.":::

Security takes you to the Role-Level Security page where you add members to a role you created. Contributor (and higher workspace roles) will see Security and can assign users to a role.

Working with members

Add members

In the Power BI service, you can add a member to the role by typing in the email address or name of the user or security group. You can't add Groups created in Power BI. You can add members external to your organization.

You can use the following groups to set up row-level security.

Note that Microsoft 365 groups aren't supported and can't be added to any roles.

:::image type="content" source="media/service-admin-row-level-security/row-level-security-add-member.png" alt-text="Screenshot showing how to add a member.":::

You can also see how many members are part of the role by the number in parentheses next to the role name, or next to Members.

:::image type="content" source="media/service-admin-row-level-security/row-level-security-member-count.png" alt-text="Screenshot showing members in role.":::

Remove members

You can remove members by selecting the X next to their name.

:::image type="content" source="media/service-admin-row-level-security/row-level-security-remove-member.png" alt-text="Screenshot showing how to remove a member.":::

Validating the role within the Power BI service

You can validate that the role you defined is working correctly in the Power BI service by testing the role.

  1. Select More options (...) next to the role.
  2. Select Test as role.

:::image type="content" source="media/service-admin-row-level-security/row-level-security-test-role.png" alt-text="Screenshot of Test as role option.":::

You're redirected to the report that was published from Power BI Desktop with this semantic model, if it exists. Dashboards aren't available for testing using the Test as role option.

In the page header, the role being applied is shown. Test other roles, a combination of roles, or a specific person by selecting Now viewing as. Here you see important permissions details pertaining to the individual or role being tested. For more information about how permissions interact with RLS, see RLS user experience.

:::image type="content" source="media/service-admin-row-level-security/row-level-security-test-role-2.png" alt-text="Screenshot of Now viewing as dropdown for a specific person.":::

Test other reports connected to the semantic model by selecting Viewing in the page header. You can only test reports located in the same workspace as your semantic model.

:::image type="content" source="media/service-admin-row-level-security/row-level-security-test-role-3.png" alt-text="Screenshot of Viewing to select a different report to test.":::

To return to normal viewing, select Back to Row-Level Security.

Note

The Test as role feature doesn't work for DirectQuery models with Single Sign-On (SSO) enabled. Additionally, not all aspects of a report can be validated in the Test as role feature including Q&A visualizations, Quick insights visualizations, and Copilot.

[!INCLUDE include-short-name]

Using RLS with workspaces in Power BI

If you publish your Power BI Desktop report to a workspace in the Power BI service, the RLS roles are applied to members who are assigned to the Viewer role in the workspace. Even if Viewers are given Build permissions to the semantic model, RLS still applies. For example, if Viewers with Build permissions use Analyze in Excel, their view of the data is restricted by RLS. Workspace members assigned Admin, Member, or Contributor have edit permission for the semantic model and, therefore, RLS doesn’t apply to them. If you want RLS to apply to people in a workspace, you can only assign them the Viewer role. Read more about roles in workspaces.

[!INCLUDE include-short-name]

[!INCLUDE include-short-name]

Related content

Questions? Try asking the Power BI Community Suggestions? Contribute ideas to improve Power BI