Hi @kkitsara ,
To address the issue, the core focus should be on configuring identity propagation correctly between Power BI and Databricks. Currently, it seems that the identity of the report developer is being used, which prevents row-level security (RLS) from being applied as intended. Here's how you can resolve this.
First, confirm that your Databricks connector in Power BI is configured for Single Sign-On (SSO) with your custom OIDC solution. This involves ensuring that the OIDC client used by Databricks can accept user-specific tokens from Power BI and pass those tokens along for identity verification. You need to verify that your OIDC setup allows the transmission of claims such as userPrincipalName or email, which can uniquely identify the users accessing the data.
In the Power BI Service, go to the settings for the dataset associated with your report. Under the dataset settings, ensure that the SSO option is enabled. This ensures that Power BI is set to pass user credentials to Databricks rather than using a static credential set. For this to work, the DirectQuery mode must be configured to use the viewer’s identity for querying the data source. Additionally, confirm that your Databricks workspace recognizes and processes the user identity passed via Power BI.
On the Databricks side, you need to implement row-level security (RLS) using user-specific attributes. For example, your table can include a column for username, and the SQL queries can filter rows using a function like current_user() or a similar attribute mapped from the user token. This ensures that only data corresponding to the logged-in user is accessible.
Testing is crucial. Use different user accounts to access the published report in Power BI Service and observe whether Databricks logs indicate the correct user identity for each query. If all queries appear to originate from the developer's identity, it points to an issue with identity propagation in the SSO configuration.
If your custom OIDC client doesn't support user impersonation natively, you might need an additional authentication layer. This can be a middleware service that maps Power BI user identities to Databricks-compatible tokens dynamically, ensuring proper impersonation.
By properly aligning Power BI’s dataset settings, Databricks authentication configuration, and RLS rules, you can enforce that each viewer uses their own identity to access the data, maintaining the integrity of row-level filtering.
Did I answer your question? Mark my post as a solution!
