Forum Discussion
Inconsistent RLS Enforcement in Paginated Report Export Based on Workspace Role
- 2 months ago
Hi tks1011 ,
Thank you for the clarification and for sharing your detailed test results.
You are correct that in your implementation the Service Principal is only used for authentication, while the logged-in user's UPN is passed through EffectiveIdentity.
Based on the behavior you've observed, EffectiveIdentity is accepted by the paginated report export API, but RLS is not being enforced in the exported output. At this time, we have not found Microsoft documentation that explicitly confirms whether this behavior is an intended limitation or a product issue for the combination of:
Service Principal authentication, Paginated report (RDL) export, End-user UPN passed via EffectiveIdentity and RLS enforcement
The available documentation suggests that this architecture is supported in embedded scenarios, but it does not explicitly describe how EffectiveIdentity is evaluated during paginated report exports:
- https://learn.microsoft.com/en-us/power-bi/developer/embedded/generate-embed-token
- https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security
- https://learn.microsoft.com/en-us/power-bi/paginated-reports/paginated-reports-rls
Because we cannot conclusively determine from the public documentation whether this behavior is an intended limitation or a product issue, we recommend raising a Microsoft Support ticket for further investigation and product-team confirmation.
To create a Fabric or Power BI support ticket, please refer to:
https://learn.microsoft.com/en-us/power-bi/support/service-support
When raising the ticket, please include your test results and the observed behavior.
Best Regards,
Abdul Rafi
Hi tks1011 ,
Thank you for the detailed testing and the workaround results.
Based on your observations, Dataset User APIs do not appear to reliably support assigning dataset-level permissions to Service Principals in this scenario, which is why the Build permission approach could not be completed via REST APIs.
When dataset ownership is introduced via the gateway-based configuration, the export succeeds, indicating that the Service Principal has sufficient access to execute the semantic model queries. However, in this elevated access state, RLS is not applied in the exported output.
This aligns with the observed behavior in paginated report exports: limited dataset access results in a Forbidden error, while elevated access allows export but bypasses RLS due to higher privilege context.
At present, there is no supported configuration that ensures both Service Principal–based paginated export execution and consistent RLS enforcement via EffectiveIdentity under varying workspace privilege levels.
Best Regards,
Abdul Rafi
Hello all,
I am facing issues while exporting a paginated report with Row-Level Security (RLS) using a service principal.
- When I assign the Admin role to the service principal on the workspace, the export is generated successfully, but RLS is not applied.
- When I assign Member or Viewer roles, the export initially fails with a forbidden access error.
To address this, I explicitly granted Build permission on the dataset to the service principal. After this change, the export is generated successfully even with Member/Viewer roles, but RLS is still not being applied.
I am using effective identity in my code to enforce RLS during export, but it does not seem to work as expected for paginated reports.
Could you please help clarify the following:
- Why is RLS not applied when using a service principal, even when effective identity is passed?
- If this behavior is a known limitation, is there any official Microsoft documentation that confirms this? If yes, could you please share the reference?
- v-moharafi-msft2 months agoCommunity Support
Hi tks1011 ,
Thank you for sharing the additional details and testing results.
Based on your testing, passing only a username through EffectiveIdentity does not appear to enforce the expected RLS filtering in this paginated report export scenario. While EffectiveIdentity is supported in export operations, RLS behavior can vary depending on the report's data source, authentication method, and export configuration.Additionally, Microsoft documentation states that RLS is enforced only for users with Viewer permissions. Users with Admin, Member, or Contributor roles bypass RLS. Service Principals also cannot be added directly to RLS roles, which may affect RLS enforcement when exports are performed using Service Principal authentication.
Relevant documentation:
Row-level security (RLS) with Power BI - Microsoft Fabric | Microsoft Learn
Best Regards,
Abdul Rafi- v-moharafi-msft2 months agoCommunity Support
Hi tks1011 ,
We hope your question and any related concerns have been resolved. If you are still facing any issues or have additional questions, please feel free to reach out.
Your update would be greatly appreciated, as it may help other community members experiencing a similar situation.
Best Regards,
Abdul Rafi - tks10112 months agoFrequent Visitor
Thank you for your response.
I would like to clarify a few important details about our implementation, as I believe there may be a misunderstanding:
- We are not passing the service principal as the username in the EffectiveIdentity.
- Instead, we are passing the logged-in end user’s UPN in the EffectiveIdentity payload to enforce RLS.
- The service principal is only used to authenticate the export API call, not to represent the user in the data context.
- Additionally, we are not adding the service principal to any RLS roles—only actual users are assigned to those roles.
Given this setup, our expectation is that RLS should be enforced based on the user identity provided in EffectiveIdentity, even though the request is authenticated via service principal.
However, in our testing:
- Export succeeds (with appropriate permissions),
- But RLS is still not being applied, even when the correct user identity is passed.
Because of this, the explanation regarding:
- Service principals not being part of RLS roles, and
- RLS bypass for Admin/Member roles
does not seem to fully explain the behavior we are observing, since we are explicitly trying to enforce RLS via EffectiveIdentity.
Could you please help clarify:
- Is RLS via EffectiveIdentity supported for paginated report export when using service principal authentication?
- If not, is this a known limitation specific to paginated reports (RDL), and is there any official Microsoft documentation that explicitly confirms this scenario?
It would be very helpful if you could point us to documentation that specifically addresses:
- Service principal + paginated report export + EffectiveIdentity + RLS behavior
Thanks in advance for your help.
- v-moharafi-msft2 months agoCommunity Support
Hi tks1011 ,
Thank you for the clarification and for sharing your detailed test results.
You are correct that in your implementation the Service Principal is only used for authentication, while the logged-in user's UPN is passed through EffectiveIdentity.
Based on the behavior you've observed, EffectiveIdentity is accepted by the paginated report export API, but RLS is not being enforced in the exported output. At this time, we have not found Microsoft documentation that explicitly confirms whether this behavior is an intended limitation or a product issue for the combination of:
Service Principal authentication, Paginated report (RDL) export, End-user UPN passed via EffectiveIdentity and RLS enforcement
The available documentation suggests that this architecture is supported in embedded scenarios, but it does not explicitly describe how EffectiveIdentity is evaluated during paginated report exports:
- https://learn.microsoft.com/en-us/power-bi/developer/embedded/generate-embed-token
- https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security
- https://learn.microsoft.com/en-us/power-bi/paginated-reports/paginated-reports-rls
Because we cannot conclusively determine from the public documentation whether this behavior is an intended limitation or a product issue, we recommend raising a Microsoft Support ticket for further investigation and product-team confirmation.
To create a Fabric or Power BI support ticket, please refer to:
https://learn.microsoft.com/en-us/power-bi/support/service-support
When raising the ticket, please include your test results and the observed behavior.
Best Regards,
Abdul Rafi