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

7eefca67 aa04-4afb-886a-bcdfb2fdafc9 on 16 Aug 2020 03:52:23

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

This is very much needed feature to restrict the data based on logged in user. Is there any plan to implement this feature?

Ramu Kodemala's profile image Profile Picture

2b769fd7 9654-47ee-a22f-72533af7baef on 16 Aug 2020 03:52:22

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

I would like to ask the Power BI team if there is a current work around for this?

Indeed - I would consider this an ´enterprise´grade feature ... so many things you could do in sales reporting for example: Store / Sales area performance, Sales commission etc.)

Ramu Kodemala's profile image Profile Picture

431581a6 37a5-4ca4-bafe-46baf59d7e7a on 16 Aug 2020 03:52:22

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

We currently have a large number of leaders and they work on different clients and we need to control what clients they can see. Glad to see that this have been started . Many thanks Power BI team !

Joe

Ramu Kodemala's profile image Profile Picture

3fb619f2 6fb3-4523-a01c-589b4f24fe3a on 16 Aug 2020 03:52:21

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

This is a very very importante feature. It would be a great thing to see this in the near future.

Ramu Kodemala's profile image Profile Picture

7cd68ace 670e-436c-b8b0-79b7e0bec19d on 16 Aug 2020 03:52:06

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

We are working on a Azure Portal to host PowerBI reports for the healthcare domain. Using AAD credentials would be very helpful as most of the users are federated by their current id providers.

Ramu Kodemala's profile image Profile Picture

e19da833 28fd-4b21-954a-72920292c780 on 16 Aug 2020 03:52:05

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

Would be great improvement for those who cannot build "SSAS with row-level secutiry + Enterprise gateway etc." that in fact very complex scenatio for many companies. Would be much easier if Power BI could manage this. For example, reserved table in data model with reserved Username field that can be "lookup" table for the rest model.

Ramu Kodemala's profile image Profile Picture

a073905b 338b-4a9b-b7ed-262a7b85c931 on 16 Aug 2020 03:52:05

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

We're working to Implement Power BI for all the schools in our district but we need to control what the user sees based on the school they work for or we run up against FERPA violations!

Ramu Kodemala's profile image Profile Picture

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

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

we are now facing this problem, how to provide customer personalized views of reports. no workaround found. Any guess of compleiting this features?

Ramu Kodemala's profile image Profile Picture

034519ac 4ff6-4157-bd15-2f889d260205 on 16 Aug 2020 03:52:02

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

Definitely needed. Users want to log in and see only what pertains to them.

Ramu Kodemala's profile image Profile Picture

fd0c30f8 c0ec-41e7-8ae4-946a8ea934e2 on 16 Aug 2020 03:52:01

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

Reoccurring problem every time I look at any of the prebuilt PowerView, PowerBI, etc. frontends for SSAS. If you were doing front end application development yourself, then you can weave the user context into the query.