Power Bi User Authentication
You set up power bi user authentication by linking workspace roles to your identity provider. Then you pick a login method for each underlying data source. Most data teams start by sharing one database account across many reports. This shortcut gets charts working fast for the whole company. Still, broad permissions expose raw tables to anyone who can edit a report. How power bi user authentication works in practice The platform splits login checks into two separate steps. First, users sign i
Multi-Factor Authentication (MFA) + User Provisioning (SCIM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up power bi user authentication by linking workspace roles to your identity provider. Then you pick a login method for each underlying data source. Most data teams start by sharing one database account across many reports. This shortcut gets charts working fast for the whole company. Still, broad permissions expose raw tables to anyone who can edit a report.
How power bi user authentication works in practice
The platform splits login checks into two separate steps. First, users sign in to the cloud portal through a central directory. This first step controls who can view or edit a dashboard. Second, the reporting tool must log in to your database to pull numbers.
Teams choose between two main ways to query the database. They can import data on a schedule or run live queries. Scheduled imports use one stored credential to pull data into memory. Every viewer then reads from that saved copy inside the reporting tool.
Live queries work in a different way. They can pass the viewer's identity straight to the database. This pass-through method requires single sign-on between the directory and the data store. When a user clicks a chart, the database checks their personal role. If single sign-on is not set up, live queries use one shared service account.
Where native database login models fall short
Native login settings do a good job of gating entry to the workspace. They verify who the viewer is before showing a chart. Row-level rules can also filter what a viewer sees on the screen. Yet these controls stop at the edge of the reporting app.
Most teams rely on shared service accounts for scheduled refreshes and basic live queries. That single account needs broad read rights across many tables to serve all reports. The database only sees the shared account name in its audit logs. It cannot tell which human user triggered a heavy or sensitive query.
Multi-Factor Authentication (MFA) + User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static secrets also create work for security teams. When you rotate a database password, you must update every linked dataset by hand. If a report creator downloads a file to their desktop, they might need local database keys. Giving direct keys to analysts expands your risk surface.
Closing the gap on shared data logins
A strong setup separates report viewing from direct database risk. Native roles decide who can open the workspace and view a dashboard. They do not inspect what individual queries do in flight against the database. Teams also struggle when sensitive fields like emails or card numbers sit in source tables.
If a report pulls a full table during refresh, those sensitive fields enter the model. Row filters only hide rows, not specific text patterns inside a column. Masking that rewrites matched fields in results keeps raw emails and phone numbers out of reports. Pairing identity checks with query-level controls gives teams clean audit trails and safer dashboards.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between workspace login and data source login?
Workspace login verifies the user opening the app through your directory. Data source login is the credential the report uses to read the database.
When should teams use pass-through identity for live queries?
Use pass-through login when the database already enforces strict user roles per table. This ensures the database checks the viewer's own identity on every click.
Why do shared service accounts create audit problems for data teams?
Shared accounts group all report queries under one login name in database logs. Auditors cannot see which person or dashboard ran a specific query.