Inconsistent RLS Enforcement in Paginated Report Export Based on Workspace Role

[tks1011]

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:

1. When the user has no access to the workspace, the export operation fails.
2. When the user has Viewer access to the workspace, the export succeeds and dynamic RLS is correctly enforced in the output.
3. 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?

[v-moharafi-msft]

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.

[cengizhanarslan]

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.

[tayloramy]

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."

[andrewsommer]

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:

1. Workspace role > determines execution context
2. 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:

1. 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.