Tableau Integrated Authentication
You set up tableau integrated authentication by linking your reporting tool to your directory service. This lets the app pass user identities straight to the database when charts load. Most data teams start with one shared service account for all dashboards. That broad role soon gives every viewer the same wide database reach. When a shared role has too much power, any chart can pull sensitive tables. Moving to user-based login ties each query back to a real person. How tableau integrated auth
Multi-Factor Authentication (MFA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up tableau integrated authentication by linking your reporting tool to your directory service. This lets the app pass user identities straight to the database when charts load. Most data teams start with one shared service account for all dashboards. That broad role soon gives every viewer the same wide database reach. When a shared role has too much power, any chart can pull sensitive tables. Moving to user-based login ties each query back to a real person.
How tableau integrated authentication works
In a standard setup, a user logs in to the reporting server first. The server checks who they are through a corporate directory or single sign-on tool. When that user opens a chart, the server needs data from the database. Instead of using a saved password, the server passes the user identity forward. This often relies on Windows domain trust, Kerberos tickets, or OAuth tokens. The database checks the ticket and runs the query under that person's role.
To make this work, admins must align identity rules across three places. The user directory, the reporting server, and the database must trust each other. You configure the reporting server to delegate login tickets on behalf of viewers. Then you map each person or group to a matching role inside the database. When the chain works, the database logs show which user ran which report. You no longer see thousands of queries coming from one generic app user.
Choosing between shared accounts and user delegation
Data teams usually pick between two ways to handle data source logins. The first option embeds one fixed database account inside the published data source. Every person who opens the dashboard runs queries as that single account. This is fast to set up, and it helps the server reuse cached results. Yet it hides who asked for the data inside your database audit logs.
The second option uses delegated login to pass the viewer's identity down. Each query runs with the exact database permissions assigned to that specific viewer. This stops a marketing user from reading finance tables through a shared chart. Still, it requires strict ticket setup and reduces how often users share cache hits. Teams must weigh fast setup against clear user tracking and tighter data rules.
Multi-Factor Authentication (MFA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native login setup solves and what it misses
Passing user identities to the database solves the problem of shared passwords. Admins do not need to type or rotate static credentials inside dozens of workbooks. If someone leaves the company, disabling their main account cuts off their chart access. Database admins also get clear logs showing which person triggered a heavy query.
Still, native login checks only decide who is allowed to open a session. Once the session starts, the database returns whatever columns that role can read. If a table holds emails, phone numbers, or card numbers, the chart pulls them. Building complex database views to hide specific columns for every role takes huge effort. Also, scheduled extracts often fail when a user token expires over the weekend. Native login proves who the user is, but it cannot rewrite results in flight.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between server login and data source login?
Server login checks who can open the reporting web app itself. Data source login controls how the server talks to the underlying database. You can use single sign-on for the app while still using a shared database key. Integrated data login connects both steps so the database sees the real viewer.
Why do scheduled extracts fail with user delegation enabled?
Scheduled extracts run in the background when the user is not logged in. Without an active user session, the server may not have a valid ticket to pass. Teams often need long-lived tokens or a dedicated extract role for background jobs.
Does passing user identity hide sensitive columns automatically?
No, passing the identity only applies the user's existing database role. If that role has permission to read a table, all columns come back by default. To hide fields like national IDs, you need row rules or dynamic data masking.