Understanding security and permissions
There are several levels of security and permissions within the Power BI service. It is important to understand these various permission levels in order to ensure that users can only access the appropriate reports, dashboards, apps, and data.
The main levels of permissions within Power BI are listed as follows:
- Workspace permissions
- App permissions
- Object permissions (dashboards, reports, scorecards, and datasets)
- Row-Level Security (RLS)
Workspace permissions
Workspaces serve as logical containers in which you can store dashboards, reports, scorecards, workbooks, datasets, and dataflows. So far, we have only worked with a single report and dataset. But workspaces can contain dozens or even hundreds of different dashboards, reports, scorecards, workbooks, datasets, and dataflows. Assigning security at a workspace level provides access to all of the objects within the workspace. This means that workspace access should only be assigned to individuals or groups of individuals that should see everything that is published or could be published to the workspace.
To assign workspace permissions, perform the following steps:
- In the Navigation pane, click on the name of the workspace, which, in this case, is Learn Power BI 2nd Edition. This changes the canvas to display the workspace interface.
- Click the Access link in the ribbon of the workspace interface. The Access dialog is displayed, as shown in the following screenshot:
Figure 10.23 – Workspace Access dialog in the service
- Similar to sharing a report, email addresses can be entered in the Enter email addresses field. Office 365 and Azure Active Directory (Azure AD) groups can be assigned as well as individuals.
Everyone that’s added to a workspace must have a Pro license unless the workspace is a Premium capacity workspace. Users can be assigned four different security roles for the workspace. These roles are listed as follows:
- Viewer
- Contributor
- Member
- Admin
The Viewer role provides the following permission:
- View items within the workspace.
The Contributor role includes the Viewer role permission, plus the following permissions:
- Publish reports to the workspace and delete content.
- Create, edit, and delete content in the workspace.
The Member role includes all of the Contributor and Viewer role permissions, plus the following permissions:
- Allow others to reshare items.
- Share an item or share an app.
- Publish and update an app.
- Add members or others with lower permissions.
The Admin role includes all of the Member, Contributor, and Viewer role permissions, plus the following permissions:
- Add/remove people, including other admins.
- Update and delete the workspace.
By default, the creator of a workspace is assigned the Admin role.
Because Office 365 and Azure AD groups can be assigned permissions to a workspace, individuals may be assigned to multiple roles for a workspace. If a user is assigned multiple roles, that individual receives the highest level of access that’s provided by the roles that they are assigned.
App permissions
App permissions relate to the users that are allowed to get and view a published app. We have already seen how to set app permissions when publishing an app.
To update an app’s permissions, do the following:
- Navigate to the workspace in the Navigation pane.
- Click on Update app in the ribbon. The Update app option replaces the Publish app option in the ribbon once an app has been published.
- Simply adjust the Permissions tab and republish the app.
Let’s continue our exploration of permissions by next looking at object permissions.
Object permissions
Object permissions refer to permissions that are assigned to individual objects within the Power BI service, such as dashboards, reports, and datasets. Unlike workspace permissions, which assign access to all of the objects within a workspace, object
permissions only assign permissions to an individual object. However, there is a hierarchy to these object permissions so that assigning permissions at one level of this hierarchy will, by default, assign certain permissions to related objects lower in the hierarchy.
To understand how object permissions work, consider that the hierarchy for dashboards, reports, and datasets is as follows:
- Dashboards
- Reports
- Datasets
- Scorecards
This is a logical hierarchy, as dashboards are built from reports and reports rely upon datasets. This means that when a report is shared, permissions are assigned for the report but are also assigned to the related dataset for that report. However, no permissions
are assigned to any dashboards. The hierarchical flow of permissions is required since dashboards, reports, and datasets are all separate, yet related objects that are dependent on objects lower in the hierarchy. For example, assigning a user permission to view a report would be useless without that user also being able to have permission to read the underlying dataset for that report. Similarly, assigning permissions when sharing a dashboard assigns the corresponding permissions for any related reports and datasets. Scorecards currently sit completely outside of this hierarchy.
Three permissions can be assigned to objects outside of workspace permission settings. These permissions are listed as follows:
- Read
- Reshare
- Build
Remember that objects can be shared either via the creation of shared links or via direct access. However, the same permissions apply in both cases. While sharing and permissions can be accessed from a variety of locations within the Power BI service, the most consistent method that works for all objects is outlined as follows:
- Navigate to the object via the Navigation pane.
- In the ribbon, click the Share option. This allows you to generate a sharing link.
- To view existing permissions, click the ellipsis (…) in the header of the sharing dialog and choose Manage permissions.
- In the bottom right-hand corner, click the Advanced link.
- The Links tab lists generated share links, while the Direct access tab lists individuals and groups with direct access to the object.
Individuals and groups with workspace access will be listed under the Direct access tab with the corresponding Permissions description, as follows:
- Admin (Owner)
- Member (Owner)
- Contributor
- Viewer
Sharing an object grants read access to the object. Reshare permissions can be added for all objects, allowing the user or group members to share the object with others.
Build permissions can only be added for dataset objects, and this allows users or group members to build new reports and content from the dataset.
RLS
In addition to workspace-level permissions, which assign permissions to everything within a workspace, and object-level permissions, which assign permissions to one or more objects, individual rows of data within a data model can be secured as well. This is the purpose of RLS, which was first introduced in Chapter 6, Unlocking Insights. In that chapter, roles were created in the Power BI Desktop application. These roles had Data Analysis Expressions (DAX) calculations that limited the rows of data that users within those roles could see.
When a Power BI Desktop file is published to the Power BI service, any roles that were created within Power BI Desktop are published to the service as part of the dataset for the report. Once published, these roles can be accessed within the service, and users can be assigned to these roles. To assign users to these roles, follow these steps:
-
To access these roles within the service, select or hover over the dataset in the
Navigation pane.
- Click the three vertical dots then click Security, as shown in the following screenshot:
Figure 10.24 – Accessing the RLS interface in the service
- Clicking on the Security link brings up the Row-Level Security interface, as shown in the following screenshot:
Figure 10.25 – RLS interface in the service
- Adding users to roles is as simple as clicking on a role, entering a user’s email address, and then clicking the Add button.
Note that RLS does not affect any other security permissions at a workspace or object level; RLS simply limits the rows of data within a data model that a user can read. Finally, it is vital to remember that users assigned Admin, Member, or Contributor permissions on the workspace are immune to (not affected by) RLS.
Summary
This chapter introduced three important types of objects in the Power BI service: dashboards, apps, and scorecards.
Dashboards are a powerful feature that allows end users to bring together all of the most important information from multiple reports, datasets, other dashboards, Q&A, and other sources into a single-page canvas consisting of tiles. These tiles can be adjusted on the canvas and allow for the creation of data alerts to immediately inform users when key metric thresholds are met.
Apps, on the other hand, allow multiple dashboards and reports to be bundled together as an independent application and published to users. These apps provide similar features and functionality to the full Power BI service.
Scorecards allow users to track and share goals. These goals can be dynamically driven by data and rules to automatically track progress.
In addition to understanding dashboards, apps, and scorecards, we have also taken an in-depth look at security within the Power BI service. Power BI provides multiple levels of interrelated security settings for workspaces, apps, scorecards, dashboards, reports, datasets, and even individual rows of datasets.
In the next chapter, we will focus on how to keep datasets that have been published to the service refreshed.
Questions
As an activity, try to answer the following questions on your own:
- What is a dashboard and what purpose does it serve?
- Which types of tiles can be added to dashboards?
- Which tiles allow for the creation of a data alert?
- What is an app and why would you use one?
- What are the two publishing methods that can be used with apps?
- Once an app has been published, how can the app be modified?
- What are the three main security/permission levels within the Power BI service?
- What are the four roles that are available for workspaces?
- What is the hierarchy of objects within the Power BI service?
- What are the five permissions that are available for objects?
Further reading
To learn more about the topics that were covered in this chapter, please take a look at the following references:
- Introduction to dashboards for Power BI designers: https://docs.microsoft. com/en-us/power-bi/service-dashboards
- Intro to dashboard tiles for Power BI designers: https://docs.microsoft. com/en-us/power-bi/service-dashboard-tiles
- Add images, text, video, and more to your dashboard: https://docs. microsoft.com/en-us/power-bi/service-dashboard-add-widget
- Add images, text, video, and more to your dashboard: https://docs. microsoft.com/en-us/power-bi/service-dashboard-add-widget
- Real-time streaming in Power BI: https://docs.microsoft.com/en-us/ power-bi/service-real-time-streaming
- Data alerts in the Power BI service: https://docs.microsoft.com/en-us/ power-bi/service-set-data-alerts
- Publish an app in Power BI: https://docs.microsoft.com/en-us/ power-bi/service-create-distribute-apps
- Get started with goals in Power BI: https://docs.microsoft.com/en-us/ power-bi/create-reports/service-goals-introduction
