MORE INFO ALL MICROSOFT CERTIFICATIONS
Skill 3.4: Configure security for dashboards, reports, and apps
5. If you do not want to notify your recipients that you shared a dashboard with them, uncheck the Send Email Notification To Recipients
6. Click Share.
At this stage, the users you shared your dashboard with will have immediate access to it. You can share a dashboard link with them directly, or they can click Shared With Me in Power BI service to see the content you shared with them.
To revise the access rights you previously granted, you can click on the Access tab in the Share dashboard pane (see Figure 3.33).
Figure 3.33 Share dashboard Access tab
By default, the app workspace in which the dashboard is published is listed as Owner in the Access tab. For every other user, you can change the level of access by clicking on the ellipsis. For example, the access level of Test User, who previously was granted Read And Reshare access, can either be removed or changed to Read.
If you click Manage Permissions, you will be taken to the Manage access page, where you will see the dashboard and the related content, such as reports and datasets. For each item, you will be able to revise the access level of each user.
NOTE SHARING A REPORT
The steps you need to follow to share a report are identical to sharing a dashboard.
MORE INFO SHARING DASHBOARDS AND REPORTS
For a video overview and more details on how you can share a dashboard or a report in Power BI service, including considerations on sharing with people outside of your organization, see “Share your Power BI dashboards and reports with coworkers and others” at
https://docs.microsoft.com/en-us/power-bi/service-share-dashboards.
Configuring access to app workspaces
If you want to allow users to edit existing reports or dashboards, or create new ones from shared datasets, you will need to give them access to the app workspace with the content you want to share. In this section, we review the steps necessary to configure access to app workspaces; app workspaces are covered in more detail in Skill 3.5: “Configure apps and apps workspaces.”
If you have an existing app workspace, you can configure access to it in one of two ways: in Power BI service or in Office 365 Admin center. In Power BI service, you can click Workspaces and then click on the ellipsis next to the workspace you want to configure access to, and click Edit Workspace (see Figure 3.34).
FIGURE 3.34 Editing workspace
NOTE EDITING APP WORKSPACES
Only workspace admins can see the Edit workspace option.
In the Privacy section, you can only change whether members can edit Power BI content; the other drop-down can only be used when you create an app workspace.
MORE INFO APP WORKSPACE PRIVACY
The Privacy section of app workspaces is reviewed in more detail in “Skill 3.5: Configure apps and apps workspaces.”
Below the Privacy section, you can see a list of members who already have access to the app workspace, along with their access rights, which can be either Admin or Member. Admins can edit workspaces and add other members to them, as well as see and edit all Power BI content in the workspaces. Members can view Power BI content and might also be able to edit it depending on the setting chosen in the Privacy section above.
To configure access to an app workspace from Office Admin center, you will need to follow these steps:
1. In Office Admin center, click Expand Navigation Menu.
2. Click Groups > Groups.
3. Click on the group that has the same name as the app workspace to which you want to configure access. Note that it will be of type Office 365 group.
4. Click Edit next to Owners, which is the equivalent of Power BI app workspace admins, or Members.
5. If you clicked Edit next to Owners, click Add Owners; if you clicked Edit next to Members, click Add Members.
6. Select the users you want to add; you can use the search bar if needed.
7. Click Save.
8. Click Close > Close > Close.
IMPORTANT APP WORKSPACE ADMINS
The users that you want to add as admins to an app workspace through Office Admin center need to be added as both Owners and Members to the relevant Office 365 group. If a user is added only as an Owner but not as a Member, she will not be able to see the app workspace in Power BI service.
Configure the export and sharing setting of the tenant
By default, Power BI content can be shared with external users and data can be exported using several options. To change the default export and sharing settings in Power BI service, click Settings > Admin Portal > Tenant Settings. The Tenant settings tab can be seen in Figure 3.35.
Figure 3.35 Tenant settings
In Tenant settings, you can see the following settings groups:
Export And Sharing Settings Content Pack And App Settings Integration Settings
Custom Visuals Settings R Visuals Settings Audit and Usage Settings Dashboard Settings Developer Settings
In this section, we review the Export And Sharing Settings. We also cover Content Pack And App Settings in Skill 3.5: “Configure apps and apps workspaces.” Other settings are out of the scope of this section.
MORE INFO POWER BI ADMIN PORTAL
For an overview of Power BI admin portal (including other tabs) as well as details on the other Tenant settings groups, see “Power BI admin portal” at https://docs.microsoft.com/en-us/power-bi/service-admin-portal.
In the Export And Sharing settings, you disable or enable the following settings:
Share Content With External Users This setting allows users to share Power BI content with users outside of the tenant.
Publish ToWeb This setting allows users to publish reports to the web as detailed in Skill 3.3: “Publish and embed reports.”
Export Data This setting controls whether users can export data from dashboard tiles and report visuals, as well as use the Analyze in Excel feature and connect live to Power BI service from Power BI Desktop.
Export Reports As PowerPoint Presentations Disabling this setting prevents users from exporting Power BI reports as PowerPoint presentations.
Print Dashboards And Report If you disable this setting, users will not be able to print dashboard or reports from Power BI service.
Each setting is enabled by default, and you can either disable it for the entire organization or enable for a subset of your organization. If you want to enable a setting for a subset of your organization, you have several choices:
Enable For Specific Security Groups Only This option allows you to enable a setting only for the groups that you specify, excluding everyone else.
Enable For The Entire Organization Except For Specific Security Groups This option allows you to disable a setting only for the groups that you specify, enabling the setting for everyone else.
Enable For Specific Security Groups While Excluding Other Security Groups This option is relevant when you have users that are part of multiple security groups, and you want to enable access for one group but disallow it to another group of users who might be part of the first group. An example of this security setup can be seen in Figure 3.36.
FIGURE 3.36 Tenant settings and security groups
If you modify settings for a feature, you will see a red Unapplied Changes message underneath the feature name. Settings are not saved automatically as you change them; to apply changes, you will need to click the Apply button.
MORE INFO EXPORTING DATA FROM POWER BI
For information on how you can export data from Power BI dashboard tiles and report visuals, see “Export data from visualizations” at https://docs.microsoft.com/en-us/power-bi/power-bi-visualization-export-data.
Configure row-level security
A common business requirement is to secure data so that different people who view the same report can see different subsets of data. In Power BI, this can be accomplished with the feature called row-level security, abbreviated RLS.
Row-level security restricts data by filtering it at the row-level depending on the rules defined for each user. To configure row-level security, you first need to define roles in Power BI Desktop and then assign users to the roles in Power BI service.
NOTE ROW-LEVEL SECURITY AND ANALYSIS SERVICES LIVE CONNECTIONS
Defining roles in Power BI only works for imported data and DirectQuery. When you connect live to an Analysis Services data model, Power BI will rely on row-level security configured in Analysis Services, and you cannot override it by creating roles in Power BI Desktop. Row-level security in Analysis Services works similarly to Power BI: you define roles and then allocate users to the roles; for more information on the topic, see “Roles” at https://docs.microsoft.com/en-us/sql/analysis-services/tabular-models/roles-ssas-tabular.
Creating roles in Power BI Desktop
To create a role in Power BI Desktop, you need to click Modeling > Security > Manage Roles, and then Create in the Manage Roles window as shown in Figure 3.37. This will create a new role with a default name of New role.
Figure 3.37 Manage roles
When you create a role, you have an option to change the default name to a new one. It is important to give roles user-friendly names because you will see them in Power BI service, and you will need to be able to assign users to the correct roles. All roles are listed in the Roles section of the Manage roles window.
If you right-click on a role or click on the ellipsis next to a role, you will be presented with the following options:
Create This creates a new role and is an alternative to the Create button below the list of roles.
Duplicate This will create a copy of the currently selected role.
Rename This will rename the currently selected role; you can also rename a role by double-clicking on its name.
Delete This will delete the currently selected role; this action can also be performed by clicking Delete below the list of roles.
For each role, you can define a table filter DAX expression for each table. When row-level security is configured, these expressions will be evaluated against each row of the relevant table, and only those rows for which the expressions are evaluated as true will be visible.
You can either type a table filter DAX expression from scratch or use the ellipsis menu next to each table to add an expression that you can then customize. The menu can also be accessed by right-clicking on a table. There are three options in the menu:
Add Filter This option lists all columns available in the table, as well as an option called Hide all rows.
Copy Table Filter From This option can copy a table filter DAX expression from another role that has a filter expression defined for the table.
Clear Table Filter This option removes any table filter DAX expression from the table; this is a shortcut to erasing all text from the Table filter DAX expression area manually.
For example, in the Wide World Importers that we previously created, you can right-click Date > Add Filter > [Calendar Year]. This will insert an expression like the following one into the Table filter DAX expression area:
[Calendar Year] = 0
Depending on the data type of a column, you might see a different placeholder DAX expression, like the following ones:
Click here to view code image // Column of type Date [Date] < DATE(2018,05,23) // Column of type Text [Calendar Year Label] = "Value"
// Column of type True/False [Is Latest]
If you decide to modify the expression, you can then validate it with the checkmark button in the top-right corner of the Manage roles window. If the expression is invalid, you will see a warning stating the syntax is incorrect below the Table filter DAX expression area, like the one shown in Figure 3.38.
FIGURE 3.38 Row-level security syntax error
Next to the checkmark button, there is the cross button, which reverts any changes that have not been applied yet.
If you want to hide all rows in a table, you can right-click on it and click Add Filter > Hide All Rows. This will add the following table filter DAX expression:
false
Because false is never going to be true for any row, no rows will be shown in this case.
In our example, we can name our role Year 2016 and create the following table filter DAX expression in the Date table:
[Calendar Year] = 2016
Also, we can duplicate the role by right-clicking on it and selecting Duplicate. We should then rename the new role to Year 2015 and modify the Date table filter DAX expression as shown here:
[Calendar Year] = 2015
IMPORTANT DUPLICATING ROLES
If you duplicate a role before you validate the last added table filter, the table filter will not be copied to the duplicate role.
Once you make the necessary changes, click Save and publish the report. In this example, we are going to publish the report as Sales RLS.
Viewing as roles in Power BI Desktop
In Power BI Desktop, you can see what the users with specific roles will see even before you publish your report to Power BI service and assign users to roles. For this, you need to have at least one role defined and click Modeling > Security > View As Roles. You will then see the View as roles window shown in Figure 3.39.
FIGURE 3.39 View as roles
Note that you can view as several roles simultaneously. This is because you can allocate a single user or a security group to multiple roles in Power BI service; in this case, the security rules of the roles will be combined using the AND logic. For example, you can select Year 2015 and Year 2016 and click OK. You will then see the report with the bar shown in Figure 3.40.
FIGURE 3.40 Now viewing report as
The report data will now be filtered to years 2015 and 2016. It is important to understand that the filters applied by row-level security are only applied at query time and not processing time. This behavior can be clearly demonstrated if you add a calculated column to the Date table with the following formula:
Click here to view code image
Number of years column = DISTINCTCOUNT ( 'Date'[Calendar Year] )
At this point, even if you view the report using the Year 2015 or Year 2016 role, or both, the column will still contain the value of 4, regardless of your choice. On the other hand, if you define the following measure, it will display different values in a Card visual, depending on whether you chose one or two roles:
Click here to view code image
Number of years measure = DISTINCTCOUNT ( 'Date'[Calendar Year] )
Another option in the View As Roles window is Other user. With this option, you can test dynamic row-level security, which is covered next.
MORE INFO ROW-LEVEL SECURITY IN POWER BI DESKTOP
For more information on how you can create and configure security roles in Power BI Desktop, including the currently imposed limitations, see
“Row-level security (RLS) with Power BI Desktop” at https://docs.microsoft.com/en-us/power-bi/desktop-rls.
Dynamic row-level security
The roles we have created so far have been static, which means that all users within a role will see the same data. If you have many rules according to which you need to secure your data, this approach might result in creating many roles, as well as updating the data model every time a new role should be introduced or an old one should be removed.
There is an alternative approach, called dynamic row-level security, which allows you to show different data to different users within the same role.
For this, your data model must contain the usernames of people who should have access to the relevant rows of data. You will also need to pass the active username as a filter condition. Power BI has two functions that allow you to get the username of the current user:
USERNAME Returns the domain and login of the user in the domain\login format.
USERPRINCIPALNAME Depending on how the Active Directory was set up, this function usually returns the email address of a user.
NOTE USING USERNAME AND USERPRINCIPALNAME
If your computer is not part of an Active Directory domain, both functions will return the same result[md]computer name\login. Once you publish your dataset to Power BI service, both functions will return the email address of the user. These functions can only be used in measures or table filter DAX expressions; if you try to use either of them in a calculated column or a calculated table, you will get an error.
To review how dynamic row-level security works using the Wide World Importers data model we created earlier in the book, we can perform the
next steps.
1. Right-click the Date table in the Fields pane and click New Column.
2. Specify the following formula:
UserAccess = "test" & FORMAT ( ‘Date’[Date], "yyyy" ) & "@xxlbi.com"
3. Create a new security role by clicking Modeling > Security > Manage Roles > Create.
4. Rename the new role to Single Role.
5. In the Manage roles window, right-click on the Date table, then click Add Filter > [UserAccess].
6. Modify the table filter DAX expression to the following one:
[UserAccess] = USERPRINCIPALNAME() 7. Click Save.
8. Click Modeling > Security > View As Roles.
9. Click the Other User and Single Role checkboxes.
10. In the text field next to Other user, type test2016@xxlbi.com.
11. Click OK.
In the steps above, we created a calculated column that contained a different email address for each calendar year. In this way, we segregated access to data for each user based on calendar year. We have done so for review purposes; in real life, sales data may be secured based on region or department, or any other business logic, and these rules are often contained in a single security table that is maintained manually.
If you followed the steps above, you would see only 2016 data, as well as the bar shown in Figure 3.41; this bar would appear at the top of the Report or Data view.
FIGURE 3.41 Viewing report as a specific user
At this stage, click Modeling > Security > View As Roles, then change the email address next to Other user to test2015@xxlbi.com and click OK. There are two things to note here:
Only 2015 data is showing now.
You are still using the same role as before Single Role.
Because you are using a single role, this approach is preferable in large-scale implementations of Power BI where there are many users that need to see different data.
If you are using bidirectional relationships, it is important to note that row-level security filters only go in one direction by default. This might yield unexpected results. For example, if we create a table that shows the Target Amount by Calendar Year Label, we will see the target for one year, but the total target amount for all years at the total level, like in Figure 3.42.
Figure 3.42 Target Amount by Calendar Year Label before applying security filters in both directions
This behavior is due to the Date table security filters not reaching the Target table because there is a bidirectional relationship between them. To make the security filters go in both directions, you need to do the following:
1. Click Home > Relationships > Manage Relationships.
2. Select the relationship that should be affected by row-level security. In our Wide World Importers example, it is the relationship between the Date table and the Calendar Year table.
3. Click Edit, which opens the Edit relationship window.
4. Click the Apply Security Filter In Both Directions checkbox. Note that this option is active only if the cross filter direction is set to Both.
5. Click OK > Close.
After you follow the steps above, you might notice that the Target amounts are now also filtered to one year only, as shown in Figure 3.43.
FIGURE 3.43 Target Amount by Calendar Year Label after applying security filters in both directions MORE INFO DYNAMIC ROW-LEVEL SECURITY