Power BI SAML-based Single Sign-On to On-Premises Data - How It Works and When to Use It

Here is a problem that catches a lot of organisations out the first time they publish a Power BI report backed by an on-premises database. On your desktop, everything works: you connect with your own credentials, the data respects whatever permissions you have, and the numbers look right. Then you publish to the service, share it with the finance team, and suddenly everyone sees everything. The row-level security you were relying on at the database has quietly stopped applying, because the report is no longer running as each viewer. It is running as one shared gateway account, and that account can see the lot.

That gap between "works on my machine" and "safe for everyone" is exactly what single sign-on through the on-premises data gateway exists to close. SAML-based SSO is one of the ways to close it, and for certain data sources it is the right one. Microsoft's documentation on gateway SSO with SAML covers the configuration. This post is about what it actually solves, when to reach for it over the alternatives, and the practical snags we hit setting it up for Australian clients.

What problem SSO is actually solving

When a Power BI report connects to an on-premises source, it goes through the on-premises data gateway, a piece of software that sits inside your network and brokers the connection between the cloud service and your local databases. Without SSO, that gateway connects using a single set of stored credentials. Every query, from every viewer, runs as that one identity. If your data source enforces security based on who is asking, and most enterprise sources do, that security never gets a chance to work, because from the database's point of view it is always the same account asking.

Single sign-on changes that. With SSO configured, the gateway passes the identity of the actual person viewing the report through to the data source. Now when Jane from finance opens the report, the query runs as Jane, and the database applies Jane's permissions. When Tom from sales opens the same report, it runs as Tom, and he sees Tom's slice. Your existing database security, the row-level rules and column permissions you have already invested in, suddenly starts working through Power BI exactly as it does everywhere else. That is the prize, and for regulated industries it is often not optional. If you are in financial services or handling anything sensitive, "everyone sees everything" is not a shortcut you get to take.

Where SAML fits among the options

Power BI's gateway supports a few flavours of SSO, and picking the right one matters, so it is worth being clear about where SAML sits.

The most common approach is Kerberos-based SSO, which works by delegating Windows identity through to the data source. It is the default answer for a lot of Windows-centric, Active Directory environments, and if that describes you, Kerberos is probably where you start.

SAML-based SSO is the alternative for data sources that speak SAML for authentication rather than Kerberos. The classic case is SAP HANA, which is the source most people are connecting to when they end up on the SAML path. Instead of delegating a Windows identity, the gateway uses a SAML assertion to authenticate the viewer against the data source. If your source supports SAML and you would rather authenticate that way, or Kerberos delegation is awkward in your environment, SAML is the route.

The practical takeaway: do not reach for SAML because it sounds more modern. Reach for it because your specific data source supports it and it fits your identity setup better than the alternatives. The right choice is dictated by what you are connecting to, not by preference. This is the kind of decision our Power BI consultants work through with clients constantly, because getting it wrong means either a security hole or a configuration you fight with forever.

What setting it up actually involves

I will not reproduce the step-by-step from Microsoft's docs, but it helps to know the shape of the work before you start, because it touches more than just Power BI.

The configuration lives in a few places at once, and that is the first thing to understand. There is work on the gateway itself, where you enable SSO and point it at the right method. There is a mapping question, because the identity Power BI knows a user by is often not identical to the identity the data source expects, so you frequently need to map between them. And there is configuration on the data source side, because it has to be set up to trust and accept the assertions coming through the gateway. Three moving parts, three places to get something slightly wrong, which is why this is rarely a five-minute job the first time.

The identity mapping is where most of the fiddly effort goes. In a lot of Australian organisations the way a user is represented in the cloud, typically by their Microsoft Entra identity, is not the same string the on-prem source recognises. Bridging that gap cleanly, so the right person is authenticated as the right user at the source, is the part that takes the care. Get the mapping wrong and you either get authentication failures, which are annoying but at least obvious, or worse, you get someone authenticated as the wrong identity, which is a genuine security problem that will not announce itself.

None of this is conceptually hard, but it does sit across the boundary between the Power BI team, the identity team and whoever owns the data source, and those are often three different people. Budget for the coordination, not just the clicks.

The honest assessment

When SSO is working, it is close to magic in the good sense: users open reports, see exactly what they are allowed to see, and never think about any of it. The security you already built at the database is simply respected everywhere, and you stop having to rebuild it inside Power BI as a second, parallel set of rules that can drift out of sync with the first. That is a genuinely clean architecture and it is the right destination for most enterprise reporting on on-prem data.

The rough parts are real too, so let me be straight about them.

Setup can be genuinely finicky, and when it does not work the errors are not always helpful about why. You will spend time in logs figuring out whether the problem is the gateway, the mapping, or the data source configuration, and the failure often does not tell you which of the three it is. This is not a piece of the stack that holds your hand.

It also depends on things outside Power BI behaving. Your identity setup has to be sound, your data source has to be configured correctly, and the network path has to allow it all. If any of that is shaky, SSO will expose it, sometimes at an inconvenient moment. SSO is not a magic layer that papers over a messy identity estate. It is more like a test of whether your identity estate is actually in order, and it will fail loudly if it is not.

My overall take: for on-premises sources where per-user security matters, SSO is not really optional, it is the correct way to build, and SAML is the right variant when your data source calls for it. But treat it as an infrastructure project with a few genuinely fiddly moving parts, not a checkbox. Give it proper time, involve the identity and data-source owners early rather than discovering you need them halfway through, and test it with real users across different permission levels before you call it done. The failure mode you are guarding against, one person seeing another's data, is exactly the kind of thing that will not show up unless you deliberately test for it.

Where to start

Before you touch the gateway, confirm three things: that your data source actually supports SAML-based SSO, that you understand how a viewer's cloud identity maps to their identity at the source, and that per-user security is genuinely a requirement rather than a nice-to-have. If per-user security is not required, SSO may be more complexity than you need, and a shared credential could be fine. If it is required, get it right from the start, because retrofitting security into a report that has already gone out with the doors open is a worse conversation to have.

If you want help getting Power BI working properly against on-premises data, security and all, that is bread-and-butter work for us. Have a look at what our Power BI consultants do, the wider Microsoft Fabric consulting we offer, and if you have got a reporting setup you want done right, get in touch.