Power BI
Under ReviewSecurity - Ability to maintain source security for reports published on BI Sites
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)
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
RE: Security - Ability to maintain source security for reports published on BI Sites
Agreed! This is definitely needed
RE: Security - Ability to maintain source security for reports published on BI Sites
How to control the data accessing by user wise, if my data is from text/excel or some other non-Microsoft data sources.
RE: Security - Ability to maintain source security for reports published on BI Sites
yes, this is vital for sharing data within the business
RE: Security - Ability to maintain source security for reports published on BI Sites
it will very useful we if get the Row based security with in the Power BI
RE: Security - Ability to maintain source security for reports published on BI Sites
Please, we need to manage security in the report itself. Inside a data model, define row security per user.
RE: Security - Ability to maintain source security for reports published on BI Sites
Yup, its must for businesses to make full use of Power BI.
RE: Security - Ability to maintain source security for reports published on BI Sites
Any update on adding role based security in PowerBI?
RE: Security - Ability to maintain source security for reports published on BI Sites
This is one of those "deal-breaker" kind of features that will determine whether one can use Power BI or not. Absolutely has to be on the immediate roadmap for Power BI.
RE: Security - Ability to maintain source security for reports published on BI Sites
This is one of those "deal-breaker" kind of features that will determine whether one can use Power BI or not. Absolutely has to be on the immediate roadmap for Power BI.