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

[RAMUK1]

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

[chris_renwick]

Without being able to pull data based on user, this product while being interesting is totally useless.

[jarkko_suominen]

This is definitely going the right direction. At least in the preview version we're able to add members to roles from our own organization. Will there be possibility to add members to roles also outside my own organization? That would be great addition to this!

[kmhaley1]

Still looking to see if there is a general solution for this without SSAS. This is crucial to implementation and may ultimately be the deal breaker that moves us to another platform.

[vijayanand103]

RLS work in Power BI portal but does not work when user exports data to analyze in Excel.

[BradW]

Why was this not fully developed in advance of the deployment of "Analyze in Excel"? Seems like a gaping security hole has been created by allowing users access to source level data without a good method of restricting access for some but not all, especially if primary distribution means are via publication to group workspaces where RLS currently does not work.

[pdebruin]

It should be possible to use the identity of the logged on user in both Power BI as well as in SQL DB/DWH etc.

[np123]

I'd love to see this expanded to respect the SQL security using pass through auth and Azure Active Directory. When using services like SQL Azure, the security model can then be built in the database - agnostic of the reporting tool on top.

[tim65]

This is also a deal breaker for us. We currently are working on a Multi-Tennant enterprise app using RLS in SQL Azure. All of our security is defined with Security Predicates in the database and we are adding the User ID in session context in our web application. We have started testing PowerBI embedded with Direct Query. With the ability to set User data in the Access Token, it shouldn't be that difficult to have PowerBI set session context after it connects to the database. It should be configurable to allow the developer to set any session context variable they choose. This would keep security where it belongs in the SQL database.

[jonathan_berger]

If I build a single report to which is applied some Row-level security, does the end-user need to buy some « application »/ « plugin » to visualize only the data he is allowed to see ? If not, how can we pass along his identity to the back end ?

[tim65]

We've implemented RLS using DAX. The queries run 10 times slower. It appears that all of the data is returned to the client and then DAX filters it. To get the performance we need, we have to have the identity passed through to SQL Azure RLS via session_context.