Forum Discussion
Inconsistent RLS Enforcement in Paginated Report Export Based on Workspace Role
I am currently implementing export functionality for a paginated report built on a dataset with dynamic RLS in a web application.
During export, I am observing the following behaviors:
- When the user has no access to the workspace, the export operation fails.
- When the user has Viewer access to the workspace, the export succeeds and dynamic RLS is correctly enforced in the output.
- When the user has Admin access to the workspace, the exported report returns unfiltered data (i.e., all user principal names are visible), effectively bypassing dynamic RLS.
This suggests that the export behavior is dependent on the user’s workspace role, which is unexpected. RLS should ideally be enforced consistently based on the effective identity provided during export, irrespective of workspace permissions.
This is the code we are using to export the paginated report with the specified format, parameters, and user identity (UPN) for applying RLS:
ExportReportRequest exportRequest = new()
{
Format = fileFormat,
PaginatedReportConfiguration = new PaginatedReportExportConfiguration(
parameterValues: (IList<ParameterValue>)request.ReportParameter,
identities: new List<EffectiveIdentity>
{
new EffectiveIdentity
{
Username = username,
}
}
)
};
Could you clarify how RLS can be consistently enforced during export irrespective of workspace roles, and whether there is a supported approach to explicitly disable or bypass RLS for paginated report exports when required?
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
19 Replies
RLS is enforced only when the caller does not already have rights that supersede it.
What you’re seeing isn’t a bug, it’s a consequence of how the export pipeline evaluates identity and permissions for paginated reports backed by a Power BI semantic model.
There are two overlapping mechanisms in play:
- Workspace role > determines execution context
- EffectiveIdentity > attempts to inject a user context for RLS
These don’t have equal precedence.
- Viewer role
The user does not have broad dataset privileges. The service must respect the supplied EffectiveIdentity, so RLS is enforced as expected. - Admin (or Member/Contributor)
The user effectively has full dataset read permissions (including “bypass RLS” capability). In this case, the service executes the query under the caller’s elevated privileges, and the EffectiveIdentity is ignored. Result: unfiltered data. - No workspace access
The export fails because the caller lacks permission to execute the report at all, EffectiveIdentity does not grant access, it only scopes it.
So, the behavior you’re seeing is consistent with the security model
EffectiveIdentity is primarily designed for service principals / embed scenarios, not to downgrade an already-privileged user.
Once a user is an Admin, the system assumes:
- They are trusted to see all data
- RLS is not a restriction for them
There is no concept of “force RLS even for admins” in this pathway.
How to enforce RLS consistently
If your requirement is: “Exports must always respect the target user’s RLS, regardless of who initiates the export” Then you need to decouple the caller identity from the execution identity.
The supported pattern:
- Use a Service Principal
- Grant the service principal:
- Workspace access (typically Member or Contributor)
- Dataset access
- Perform export using the service principal token
- Pass EffectiveIdentity with the target user’s UPN
This ensures:
- The export always runs in a controlled, non-human context
- RLS is applied strictly via EffectiveIdentity
- No accidental privilege escalation from workspace roles
This is the standard pattern for Power BI Embedded and secure export workflows.
Hi andrewsommer ,
Thank you for the response. I wanted to clarify that our implementation is already using a Service Principal with client credentials (AcquireTokenForClient — OAuth 2.0 client credentials grant). The user's delegated token is never forwarded to the Power BI API. The SP token is what authenticates the export call, and the user's UPN is only passed as EffectiveIdentity inside the request payload.
We are also passing a Service Principal Profile ID for the paginated report path — so the SP is not operating with direct elevated workspace permissions either.
Despite this, we are still observing that RLS is bypassed when the end user has Admin-level access to the workspace. This is unexpected because the export is being initiated entirely under the SP + profile context, not the user's context.
To summarize our setup:
- Export API call authenticated via SP client credentials (not user token)
- SP Profile ID is being passed correctly
- EffectiveIdentity with the target user's UPN is passed in PaginatedReportExportConfiguration
- RLS is correctly enforced for Viewer-role users, but bypassed for Admin-role usersIs there something specific about how Power BI resolves identity for paginated report exports that could cause the end user's workspace role to still influence the output, even when the call is made under a SP + profile context? Any guidance would be appreciated.
What we tested and what we found
- Baseline export (no security context)
What we tried:
{
"format": "PDF"
}
Result: Success
Finding: The export pipeline, workspace access, and paginated report configuration are functioning correctly - EffectiveIdentity with only username
What we tried:
{
"format": "PDF",
"paginatedReportConfiguration": {
"identities": [
{
"username": "[email protected]"
}
]
}
}
Result: Export succeeded
Issue: No row-level filtering was applied; full dataset was returned
Finding: Passing only username does not enforce RLS for paginated report export - EffectiveIdentity with datasets
What we tried:
{
"format": "PDF",
"paginatedReportConfiguration": {
"identities": [
{
"username": "[email protected]",
"datasets": [
"dataset-id"
]
}
]
}
}
Result: Failed
Error: InvalidRequest: Exporting a paginated report with an effective identity with datasets is not supported
Finding: Dataset-scoped EffectiveIdentity is not supported for paginated report export - Passing roles
What we tried:
{
"format": "PDF",
"paginatedReportConfiguration": {
"identities": [
{
"username": "[email protected]",
"roles": [
"RoleName"
]
}
]
}
}
Result: Did not work
Issue: No RLS behavior observed
Finding: Roles do not enable RLS in the paginated export flow - Passing parameters
What we tried:
{
"format": "PDF",
"paginatedReportConfiguration": {
"parameterValues": [
{
"name": "ParameterName",
"value": "ParameterValue"
}
]
}
}
Result: Works only when parameters are pre-defined in the report
Limitation: Requires the RDL to be explicitly designed with parameters
Finding: Parameters can act as a workaround but are not a generic RLS substitute - Passing CustomData
What we tried:
{
"format": "PDF",
"paginatedReportConfiguration": {
"identities": [
{
"username": "[email protected]",
"customData": "some-value"
}
]
}
}
Result: Not applicable
Finding: CustomData works only in Analysis Services / semantic model scenarios and is not supported in this paginated export flow
- Baseline export (no security context)
Hi tks1011,
andrewsommer is correct. Any user that has contributor or higher permissions in a workspace will bypass RLS.
Those users all would have permissions to edit the RLS rules anyway, so even if RLS was applied they could edit the rules and bypass it.See the microsoft docs: https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security
"RLS only restricts data access for users with Viewer permissions. It doesn't apply to Admins, Members, or Contributors."
Workspace Admins and Members bypass RLS entirely in Power BI. This is a documented platform rule that applies to both interactive report viewing and API-based exports. The effectiveIdentity parameter in the export API cannot override this bypass for users who have Admin or Member workspace roles.
Hi tks1011 ,
Thank you for reaching out to Microsoft Fabric Community and Thanks to cengizhanarslan , tayloramy and andrewsommer for Sharing valuable insights.
Just wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.Best Regards,
Abdul Rafi.
Hi tks1011 ,
Thank you for your patience.
Even when using a Service Principal with EffectiveIdentity, paginated reports in Microsoft Power BI don’t enforce RLS in the same way as semantic model (PBIX) queries. The export pipeline has limitations and does not support dataset-scoped identity, roles, or datasets, so passing only a username doesn’t reliably apply row-level filtering.
This also explains why Admin users see unfiltered data. Users with elevated workspace roles already have full dataset access, so RLS is not applied to them. This behavior is expected.
RLS applies only to Viewer users and is not enforced for Admin, Member, or Contributor roles. Since EffectiveIdentity cannot override workspace permissions and has limited support in paginated exports, RLS cannot be enforced for users with elevated access in this scenario.
If consistent filtering is required regardless of user role, the recommended approach is to implement parameter-based filtering within the RDL pass values via parameterValues and enforce filtering directly in the query (SQL or stored procedures). This ensures consistent and role-independent results.
For more information, please refer to the documentations:
Set Up Row-Level Security in Power BI Paginated Reports - Power BI | Microsoft Learn
https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-securityBest Regards,
Abdul RafiHi v-moharafi-msft ,
We tested exporting paginated RLS reports by passing parameters, and that scenario works correctly. However, we also want to support exporting paginated RLS reports without parameters.
For this, we assigned the Service Principal the Viewer role on the workspace, but in the embedded report experience, exporting paginated RLS reports returns a Forbidden error. At the same time, exporting regular PBIX reports works successfully with the same Viewer access for the Service Principal.
Could you help us understand this behavior? Is the Forbidden error occurring because the Viewer role does not provide sufficient dataset access, and dynamic RLS evaluation for paginated reports requires dataset-level permissions in order to apply RLS?
Hi tks1011 ,
Thanks for the update.
The behavior suggests that Build permission on the underlying semantic model/dataset may also be required for paginated report exports that rely on EffectiveIdentity and dynamic RLS evaluation. Workspace Viewer access alone does not grant permission to query the semantic model used by the paginated report.
As a workaround, please try granting the Service Principal Build permission on the semantic model/dataset and then re-test the paginated report export scenario. Also note that RLS is enforced only for Viewer users. Admin/Member/Contributor roles bypass RLS by design.
Please refer to the following documentations for more information:
1. https://learn.microsoft.com/en-us/power-bi/connect-data/service-datasets-build-permissions
2.https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-securityBest Regards,
Abdul Rafi
Hi tks1011 ,
We wanted to check if your question has been resolved or if you are still facing any confusion feel free to reach out. Providing an update can be beneficial for others who might be experiencing similar challenges.Best Regards,
Abdul Rafi
Hi tks1011,
Could you please confirm if the issue has been resolved? If not, feel free to reach out if you have any further questions.
Your update would be helpful for other members who may face a similar issue.
Best Regards,
Abdul Rafi
Hi tks1011 ,
Could you please confirm whether a support ticket has been raised for this issue? If so, we would appreciate it if you could share any findings or resolution details with the community, as this may benefit other members who may face same issue.Thank you for your understanding and assistance.
Best Regards,
Abdul Rafi
