Allowing Only Tableau Vizes with Unrestricted Trusted Authentication, SAML or OIDC

Editor’s Note: Huge thanks to Robin Cottiss who helped me navigate the world of authentication in Tableau as he has for so many years to be able to write this. He doesn’t have the same online presence as a lot of other Tableau wizards but I can’t say how much of my and others Tableau knowledge that is out there has either been guided by or just a straight repackaging of the hard-gained work Robin has put in.

When embedding Tableau vizes for external use, the three most common SSO mechanisms are Trusted Authentication, SAML, and OpenID Connect (OIDC).

Trusted Authentication or Trusted Tickets has two modes, which are set as server-level flags:

  • Restricted (default): A user can only see Vizes, and cannot see the full Tableau Server UI.
  • Unrestricted: Redeeming the ticket creates a full session to Tableau Server, and the user can see the full Tableau Server UI

SAML and OpenID Connect always create a full session, so they work like Unrestricted Tickets.

Additionally, Restricted Trusted Tickets (the default Trusted Authentication mode) also disables:

  • Custom Views
  • Subscriptions
  • Alerts
  • Other interactions with Web Edit, Ask Data, etc.

Many customers would prefer to have a session started with any of the three SSO mechanisms, that allows all the Viz features, but doesn’t let the user ever get to the full Tableau Server UI. Is it possible?

Blocking only the Tableau Server UI

All you have to do to block the Tableau Server UI, while allowing embedded visualizations, is have your web server / reverse proxy / load balancer implement a rule like:

IF URI Exactly Matches "/" THEN Return 403 Response

I’ve tested this solution with both Unrestricted Trusted Tickets and SAML, and with both AWS Elastic Load Balancer and Azure WAF.

You can add more detail around the rule – for example you may want it to only apply to people coming in externally, but not users within your own internal corporate domain. You may want to have a different response than 403. But if you block only the root URI (“/”), SSO and embedded visualizations will still work while there will be no access to the Tableau Server UI.

How does this work?

If you go into Tableau Server directly, you’ll notice the URLs you see in the browser always have a # symbol. For example, https://{server-url}/#/signin or https://{server-url}/#/explore.

Tableau Server (at time of writing) is a single-paged app — that is to say, regardless of what your URL looks like, it is always starting a loading the same main page, and then never actually transitioning away from that first page. Instead, it is constantly requesting different content and replacing what you see in the same page.

If you actually were to look at the web server logs of Tableau Server, you would see that both of the pages listed above come through simply as:

“/”

Just the bare forward-slash. The portion of a URL from the # onward in a browser is never even sent to the web server itself. Don’t worry if this doesn’t feel right – it’s a very modern way to architect a web application and really different from any type of basic things you would be taught in any introductory course.

It also means it is very difficult to block specific pages – this technique really is there to achieve the same effect as Restricted Trusted Tickets in a SAML or OIDC session, or without turning off the other features that go along with Restricted Trusted Tickets.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s