Skip to main content

Power BI

Under Review

Security - Ability to maintain source security for reports published on BI Sites

Vote (1710) Share
Ramu Kodemala's profile image

Ramu Kodemala on 03 Mar 2015 07:53:46

The general requirement is that visualizations (Power View, SSRS etc...) must not circumvent existing policies, or introduce yet another set of security policies on top of those already implemented at the source.

* For example, a visualization of sales data needs to reflect the policy that account managers can only read sales data for their region.
* For performance reasons, this is enforced at the source by injecting predicates into the query based on the end users identity. If identities for end users are not passed down the process chain into the data layer, it leaves us little option but to publish individual reports for every region, which results in an explosion of complexity and numbers of reports, or move the whole model to BISM and manage the policy in yet another place (namely the BISM model).

Impact
blocking migration to SPO/BI Sites. At least 412 Site Collections with more than 600 Power Views. Impacting Adoption or migration for majority of BPUs - e.g. Finance, LCA, HR, etc

Administrator on 16 Aug 2020 02:15:30

Hey all! We've continued to make progress here, so I wanted to update this thread with our current capabilities for maintaining security on dashboards/reports. As always, all of this information can be found in our Row-Level Security (RLS)documentation: https://powerbi.microsoft.com/en-us/documentation/powerbi-admin-rls/ > If you have set up RLS in Analysis Services, Power BI will send the signed-in user's credentials to Analysis Services, and respect the RLS rules set up on the on-premises model. > Separately, you can set up RLS in Power BI for data sources that you import or connect to via DirectQuery. This process starts in PBI Desktop, where you define roles, and write DAX to constrain what data these roles can see. As part of this process, can you use the UserPrincipalName () DAX function to get the current signed in user's UPN (e.g. joe@contoso.com). Then, once you publish to service, you can assign users to these roles. Does the above meet your requirements? Please let us know via comments or e-mail. Those of you who requested that the identity of the signed in Power BI user be pass through to Azure SQL, SQL DB, DWH, etc.: we hear you - that is under consideration. Thanks, -Sirui

Comments (143)
Ramu Kodemala's profile image Profile Picture

c8bdd773 d7c6-4825-9797-214516d55e98 on 16 Aug 2020 03:51:07

RE: Security - Ability to maintain source security for reports published on BI Sites

Yep, agree with other comments. This would make life so much easier.

Ramu Kodemala's profile image Profile Picture

9439b1e4 fbc2-ea11-a812-000d3a563be2 on 16 Aug 2020 03:51:07

RE: Security - Ability to maintain source security for reports published on BI Sites

This is becoming a serious issue particularly because PowerBi Designer models cannot be promoted into Analysis Services. One of the "simple" ways to do this is to enable USERNAME () function in powerbi.com so that any existing PowerPivot or Designer based model can be secured. Ultimately, security needs to become an integral part of the service just like collaboration but in the short term, making USERNAME () function work would be very helpful.

Ramu Kodemala's profile image Profile Picture

aa1eeead 2da4-4dbc-8e8f-22448ee36e37 on 16 Aug 2020 03:51:06

RE: Security - Ability to maintain source security for reports published on BI Sites

We are creating dashboards which must be used by multiple clients. But the client must only sees his/her data, the data is loaded via Azure SQL Database. So a kind of row level security must be available. What can we expect to enable this functionality?

Ramu Kodemala's profile image Profile Picture

176c5e3f 7583-4565-bef6-42c16afefef8 on 16 Aug 2020 03:51:02

RE: Security - Ability to maintain source security for reports published on BI Sites

Yes but this eliminates much of the usefulness in regulated environments such as HIPPA and others. It makes this almost useless in any areas with regulation. It can be optional for only those that really need it.

Ramu Kodemala's profile image Profile Picture

348aa0f4 09f9-4847-8abe-5778158604bf on 16 Aug 2020 03:51:01

RE: Security - Ability to maintain source security for reports published on BI Sites

'This issue applies to Power BI Preview as well for all data sources that support row level security including:
- SQL Server DB
- SQL Azure
- SSAS MDX

Ramu Kodemala's profile image Profile Picture

8a81ea11 577e-4d7a-808b-37474d47442f on 16 Aug 2020 03:50:59

RE: Security - Ability to maintain source security for reports published on BI Sites

I would also love to see row-level security within Power BI. I'm used to creating row/role based security in a tabular model.

Ramu Kodemala's profile image Profile Picture

6015e795 3b4a-45e1-aa04-c5a7da0fa509 on 16 Aug 2020 03:50:58

RE: Security - Ability to maintain source security for reports published on BI Sites

Adding row-level security within Power BI would be fantastic.
At the moment dax rules could be applied via ssms locally to the designer file. Do these carry over when the designer file is loaded? Even if that was supported it would be something.

Ramu Kodemala's profile image Profile Picture

f69a8a55 1545-4a29-932b-f9e8623cb810 on 16 Aug 2020 03:48:32

RE: Security - Ability to maintain source security for reports published on BI Sites

Any update on the status of this? This is a must have feature for Power BI to deploy directly and not to have to have Analysis Services Tabular model

Ramu Kodemala's profile image Profile Picture

290dfd97 2467-4fb8-bb50-92c761a445bd on 16 Aug 2020 03:48:32

RE: Security - Ability to maintain source security for reports published on BI Sites

Any news?

Ramu Kodemala's profile image Profile Picture

25073ae5 0ba1-45b7-bcd5-d72c56c82b1c on 16 Aug 2020 03:48:31

RE: Security - Ability to maintain source security for reports published on BI Sites

Ability to filter data based on user. Would be able to filter down data for each user in the shared list to only the data we want them to see.