Tableau Authentication
You set up tableau authentication by linking your analytics app to an identity provider. Then you map user groups to site roles and set database login rules. Most data teams start with a single shared database login for all dashboards. That fast setup works early on, but broad database roles create big security risks. When every report uses one master login, you lose track of who ran each query. Anyone who can build a report can pull raw tables with sensitive customer records. How tableau auth
Multi-Factor Authentication (MFA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up tableau authentication by linking your analytics app to an identity provider. Then you map user groups to site roles and set database login rules. Most data teams start with a single shared database login for all dashboards. That fast setup works early on, but broad database roles create big security risks. When every report uses one master login, you lose track of who ran each query. Anyone who can build a report can pull raw tables with sensitive customer records.
How tableau authentication works across users and data sources
A complete setup has two distinct steps. First, the user logs in to the analytics platform itself. Second, the platform logs in to the backing database to run queries. Teams manage the first step with single sign-on protocols like SAML or OpenID. Your identity provider checks the user and sends a signed token back. The platform reads that token and places the user into a site role.
The second step decides how the platform talks to your data store. Admins can embed a shared service account inside the published data source. Every person who opens that dashboard runs SQL under that single shared account. As another option, teams can pass the viewer identity straight to the database. This pass-through method uses OAuth tokens from the user session. The database then checks its own role rules before it returns any rows.
Choosing between shared accounts and viewer credentials
Shared service accounts make report publishing simple for creators. Viewers do not need their own database accounts to read a chart. Background extract jobs can also run on a schedule without a human logged in. Still, the database log only shows the shared service account name. If a bad query slows down the cluster, you cannot tell who triggered it. You also have to build row filters inside the report layer to hide data.
Passing viewer credentials fixes the audit trail problem at the database level. Each user needs a valid role in the data store before charts will load. The database applies its own table rules to every single query. Yet this setup adds heavy admin work across large teams. You must keep user groups in sync between your identity tool and every database. Scheduled extracts also fail when a user token expires overnight.
Multi-Factor Authentication (MFA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native login rules solve and what they leave open
Native login setups do a great job verifying who can open the app. They also control which folders, workbooks, and data sources a group can see. When you pair single sign-on with database roles, you block unknown users right away. That stops outside threats and keeps casual viewers out of admin menus.
Still, login checks only happen at the start of a session. Once a session starts, the native setup does not inspect individual SQL statements in flight. An analyst with valid login rights can still pull full columns of private data. If a table holds emails, phone numbers, or card numbers, custom queries return them intact. Native site roles cannot rewrite those matched fields in query results on the fly. They also cannot pause a risky query and ask a manager for live approval. Teams need controls that inspect each query and mask national IDs before results return.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between site login and data source login?
Site login checks who can open the analytics app and view folders. Data source login controls how the platform connects to your database to run SQL.
Why do scheduled extracts fail when using viewer credentials?
Scheduled extracts run in the background without an active user session. If the saved OAuth token expires, the database rejects the background query.
Does single sign-on hide sensitive columns inside a dashboard?
No, single sign-on only checks user identity at login time. To protect emails or card numbers in results, you need query-level data masking.