The SAML authentication request is handled solely through the client browser as a base-64 encoded post variable. So, in theory, you shouldn't even need the authentication parts of Tableau to be in the DMZ.
But - that aside - while it would be possible to separate the tableau server processes to different nodes in a cluster, and then have some nodes behind the DMZ and some nodes in the DMZ, I'm not 100% convinced that you wouldn't run into performance problems due to network latency between the nodes. A more-common solution would be to add a reverse proxy in the DMZ, and keep the entire tableau server environment behind the DMZ.
Thanks a lot for the response.
I think what's at the heart of the issue is that, although the SAML piece is base-64 encoded, one would be opening up unauthenticated traffic into the companies internal network as the initial login request has to go to Tableau Server first (SP init requirement by Tableau) before being authenticated, and from what I'm hearing, unauthenticated traffic into the internal network is a huge no-no (independent of Tableau).
Would the same argument for network latency apply to clusters regardless of DMZ implications? i.e. I get that there may be some slight network overhead with the dmz port forwards, but in practice they could just be boxes sitting right next to each other in our data center, correct? I guess this is the sort of thing I'm looking to see if anyone has tested.
As for the reverse proxy, I was actually just taking a look at that and I'm curious to see what that could provide. Is it basically just a relay? Or can it be authenticated at the proxy level in the dmz and then pass the user along to the Tableau server internally?
2 of 2 people found this helpful
DMZ questions aside, I worry that we may be operating on false assumptions here. I think there are definitely strategies that can be used to expose Tableau to public traffic if that's what you want. But, the use of SAML doesn't typically require that.
The initial request comes from the user hitting Tableau Server in their browser. In order to do this, the user would need to be in the DMZ, and authenticated through normal IT processes. (Unless you opened up the Tableau port in the firewall to external traffic)
In most setups, the users are either in the LAN network already, or connected through a VPN.
Basically, the SAML Flow goes something like this:
1) User hits Tableau Server, Tableau Server determines if the user is logged in already.
2) If not, the user is forwarded to the SAML authentication page with some POST data detailing the login request. (On or off DMZ, depending on the SAML IDP's location)
3) User logs in on the authentication page
4) User, now logged in, is forwarded back to Tableau Server with new POST data, detailing the user's credentials.
Because of this, you can house the entire solution inside the DMZ, unless you have a need to serve external users.
Let me know if that fits your scenario?
To answer your other questions:
The network latency concern is only a small one, and just something that would need to be tested.
The reverse proxy is typically the method I've seen for exposing Tableau server to public traffic in a somewhat-protected manner. By default it's basically a relay, but additional traffic handling rules can be applied.
Hopefully this helps. Also - as specifics to your environment may be applicable, we can always discuss more via email if you'd like. My email is email@example.com
Mat Hughes wrote:
...unless you have a need to serve external users.
This is exactly what we are doing and is where the question/challenge is coming from.
Was hoping to catch someone here who has experience isolating the pieces of the server required for gateway and authentication from the underlying data structures (extracts).
1 of 1 people found this helpful
We have a 8 core Tableau server license that we have on the DMZ. The back end consists of several SQL databases that the extracts are generated from and those live behind the firewall. But the extracts themselves live on the Tableau server because that's the way the Tableau server works.
Even if you could put the extracts on a separate server, I'm not sure what it would buy you in terms of security. After all, the data from the extracts ultimately will be exposed on the front-end Tableau server via XML or simply in RAM once the visualization is used. A better approach would be to make sure that sensitive data are excluded from extracts to begin with.
And design considerations aside, what does your license situation looks like? While it may be possible to come up with a cluster configuration that would meet your security wishes, would you have the Tableau licensing to support it?
1 of 1 people found this helpful
Great insight, Glen. I appreciate it
We also have an 8-core based license. Unfortunately once the users get a taste for the extracts they don't want to go back. I have been in many discussions asking to try connecting live (for multiple reasons, i.e. we have enterprise level DBs and intensely designed reporting star schemas in place) and the answer is invariably, "Nah". My response, "but you just uncheck the extract check mark, and can check it back easily". Response: "interesting, but nah". OK.
I don't think the vulnerability concern is when the data/extract is being accessed by an authenticated user, but rather that the connection itself is to a publically available server (the Tableau Server) that holds the extracts. If that server is compromised the TDE's would be directly available to the attacker.
I understand that there is no ultimate security in that even if we somehow put the data engine internally behind the firewall, that theoretically once the server in the DMZ is compromised that the attacker could do a port scan and see what is available and physically get to the extracts, but it's an extra layer (admittedly one I don't fully understand), but a layer nonetheless.
Not to mention this seems to be a fairly common practice from what I'm hearing (Both by other BI tools, and from our infrastructure team).
1 of 1 people found this helpful
I don't think you'll be able to do it, Brian. The extracts live on the server.
I hear what you're saying about the server being compromised, but even if the extracts did live elsewhere, a sophisticated attacker could do a memory dump and pull the data that way too. Maybe not all of it, but enough.
You might be better off looking at putting Tableau behind the firewall and having a RDP or Citrix gateway in the DMZ instead.
Along those same lines (assuming you're using gateway and proxy interchangeably,which I'm not sure one can), this looks promising:
Basically, can authentication be handled at the proxy level? And, if so, does it take away any functionality? (i.e. like Desktop/Mobile App functionality, which that KB article addresses).
I believe we do have F5's so that would be a nice solution.
I was thinking gateway more like application gateway. For example, you could setup Remote Desktop / RemoteApp. Users would authenticate at a Remote Desktop gateway and then they could launch Tableau Server. It would appear as if it were running on locally, but the browser would actually be remote. Performance might get hairy.
But yes, reverse proxy could do the trick. You should be able to get F5s to do that for sure.