Share via

Integration with SSO login on-premises (non-fabric and non-cloud) PowerBI Reporting Server

Samir Modi 0 Reputation points
2026-03-02T09:59:16.6233333+00:00

Hi,

We need to understand the standard integration process of integration SSO login (with PowerBI Reporting Server) wherein the flow is following :

  1. FSSO login happens and a SAML token is generated by the service provider.
  2. Using above SAML token, we need to authenticate/authorize users in Power BI Reporting Server, it can be existing or a completely new user.
  3. Add additional user metadata in session information so that it can be accessed using DAX query in PBIX files for applying row level security (RLS)
SQL Server Reporting Services
SQL Server Reporting Services

A SQL Server technology that supports the creation, management, and delivery of both traditional, paper-oriented reports and interactive, web-based reports.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. kagiyama yutaka 1,170 Reputation points
    2026-03-04T13:42:02.0366667+00:00

    PowerBI Report Server can’t authorize user from SAML token, so any SAML‑based SSO must be converted into Windows identity throug C2WTS or KCD before PBIRS can use it. RLS can only evaluate Windows UPN or AD groups, because PBIRS has no mechanism to expose SAML claims inside DAX.

  2. Q&A Assist
    2026-03-02T09:59:29.4833333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Power BI Report Server and SQL Server Reporting Services support custom authentication and security extensions, but the provided context does not describe any supported or documented flow where an external SAML token (such as from FSSO) is directly consumed by Power BI Report Server to:

    1. Authenticate/authorize users based on that SAML token, or
    2. Surface arbitrary user metadata from that token into DAX for RLS.

    The SAML-based SSO described in the context applies to Power BI Service with an on-premises data gateway, specifically for SAP HANA, where the gateway acts as a SAML identity provider for the data source, not for authenticating to Power BI Report Server itself. In that model:

    • SAML is used between the gateway and SAP HANA to respect user-level permissions on the data source.
    • Power BI Service uses Windows Authentication to access the gateway.
    • RLS is applied in Power BI datasets/semantic models, and SSO is used to pass the effective identity to the data source (for example, Azure SQL or SAP HANA), not to inject arbitrary SAML metadata into DAX.

    The token-based identity (SSO) model in the context is also specific to Power BI Embedded with Azure SQL Database, where:

    • An ISV app acquires a Microsoft Entra access token for Azure SQL.
    • That token is used to define the effective identity when generating an embed token.
    • RLS is enforced in Azure SQL or in the Power BI semantic model based on that identity.

    This model is not described as available for Power BI Report Server.

    Given the context, the standard, supported SSO and RLS patterns are:

    • For Power BI Service with on-premises data sources: use Kerberos or SAML SSO via the on-premises data gateway, and configure RLS in the Power BI dataset or semantic model. The gateway impersonates the user to the data source; user identity is based on the Power BI user (UPN) and gateway configuration, not on an externally supplied SAML token.
    • For Power BI Embedded with Azure SQL: use token-based identity with a Microsoft Entra access token for Azure SQL, and apply RLS in Azure SQL or the semantic model.

    The context does not document:

    • A way to plug an arbitrary external SAML token (from FSSO) directly into Power BI Report Server authentication.
    • A mechanism to expose arbitrary SAML claims or custom metadata from such a token into DAX expressions in PBIX files hosted on Power BI Report Server.

    Any solution that attempts to:

    • Accept an external SAML token for PBIRS sign-in, and
    • Surface its claims as session metadata into DAX for RLS

    would require custom extensions and behavior that are not covered or supported by the documentation in the provided context.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.