Enforce Role Inheritance from Snowflake in Power BI Tenant Settings
We would like the setting ‘Report viewers can only access this data source with their own Power BI identities’ to be enforced at the tenant level, rather than being left as an optional configuration for individual report creators.
In our scenario, Snowflake is used as the data source, with Role-based Access Control (RBAC) in place: access privileges are assigned to roles, which are then are assigned to users. This measure helps secure access to sensitive data. For data governance and compliance purposes, we must ensure that, at the Power BI tenant level, only authorized users can access this data. Power BI must inherit this Snowflake security measure, ensuring that access controls based on roles and privileges are consistently enforced across both platforms.
However, we observed that when creating a Power BI report that reads confidential data from Snowflake using DirectQuery with Role-Based Access Control (RBAC), users who do not have access to the corresponding confidentiality role in Snowflake can still see the data, if this setting is not enabled.
In the Power BI Service, under Data Source Credentials, there is an option labeled:
“Report viewers can only access this data source with their own Power BI identities.”
If this option is selected, the role applied at the Snowflake level is enforced, and unauthorized users cannot view the data. However, if the report creator does not select this option and shares the report with viewer access, even with DirectQuery, those users will be able to see the confidential data, which violates the confidentiality controls defined in Snowflake.
That said, we are requesting that this setting be enforced at the tenant level to ensure it is not left to users' discretion. This security measure should be applied automatically, in alignment with our company's security policies, rather than relying on individual users to enable it.
1 Comment
- pacifist
Helper II
I see where is this coming from, but this should be solely a developer responsibility to ensure the access to the DQ type of data is restricted by using the SSO passthrough (so the authentication happens on the Snowflake level). Then in the case of import mode per confidential table, how would you enforce it? I agree, more integrated role based access between the two would be nice, but I think it's the long way off.
Recent ideas
Display Table[Column] instead of Column Name in Conditional Formatting Dialogs
In large-scale Power BI semantic models, it is common to have identical column names across multiple fact and dimension tables. Examples include columns such as Status, Category, Region, Employee ID,...Manickambeeie1 hour agoNew MemberNew3Views0likes0CommentsNative SAP SuccessFactors and Active Directory Connectivity for Simplified Data Integration
Having native connectors for SAP SuccessFactors and Active Directory would eliminate the need for workarounds such as notebooks, custom scripts, or complex integration setups. Users should be able...João_Cristo2 hours agoNew MemberNew3Views0likes0CommentsAllow Azure Databricks streaming tables to be mirrored into Fabric
Mirroring an Azure Databricks Unity Catalog into Fabric silently drops streaming tables. They are not greyed out, not flagged, not explained. They simply do not appear in the picker, so there is no w..._taab3 hours agoNew MemberNew5Views0likes0CommentsPower BI, import report and semantic model: show change connection pop-up
When you need to import an existing Power BI report and semantic model in Tenant B that's created in Tenant A, you need to jump through a number of hoops to fix the original connection. It's doable, ...Reitse4 hours agoMost Valuable ProfessionalNew13Views1like0Comments