[I don't seem to turn up any discussion on this, please forgive me if I duplicate...]

I am a Tableau Server admin managing a multi-site server. Each site will be sharing content via trusted ticket from their respective web servers in other locations. As the server admin, I will be responsible for adding their IPs to the trusted list. Over time, I'm assuming that I will need to add and remove IPs to/from this list on a periodic basis. My first site has required the addition of 14 IPs to the list. From this number, it seems that as more sites are added from other locations, I could very well be looking at managing a few dozen IPs.

So here's the rub: The command line (tabadmin) approach works fine for a small number of IPs, but will become a real pain if I'm managing dozens of IPs. Personally, I would prefer an alternative. (Why not add this to the Tableau Server Configuration application?)

I have poked around and found that the list is stored in the tabsvc.yml file in the server config. I'm assuming that this is where the server picks up the "tabadmin set wgserver.trusted_hosts <list>" additions upon restart. You've probably seen this question coming: Can I just edit the tabsvc.yml file directly via notepad and effect the same changes?

On other beef that I have with the documented approach via "tabadmin" is that it seems that the only option is "set" for the trusted IPs. Is it not possible to print a list or delete entries to this IP list? I guess maybe I'm in an atypical situation here, in that I will be managing this server for use by multiple other institutions, but if any of you have advice or insights I will certainly welcome them.

As the server admin, I will be responsible for adding their IPs to the trusted list. Over time, I'm assuming that I will need to add and remove IPs to/from this list on a periodic basis. My first site has required the addition of 14 IPs to the list.

So if I understand it, this particular customer has 14 app servers, each with a distinct internet-facing IP address? You aren't actually adding an IP address for each of 14 "users" associated with this customer, right?

(If the answer to the second question is "Yes, that's exactly what I'm doing", then it's important you say so - this is a bad thing to do and we can give you alternatives - actually, see below)

Anyway - What most folks do who are hosting a multi-tenant implementation of Tableau Server w/ Trusted Tickets do is the following:

They don't attempt to keep a dynamic list of X IP addresses-per-tenant in trusted_hosts. That's way too hard

Instead, they create a "Ticket Granting Web Service" that THEY write and host.

You tell Tableau Server to trust ONLY the IP of your ticket granting web service

Each tenant authenticates against this web service in a way that it is clear to YOU which site they are from - that way you can create tickets from the appropriate site/customer

Your customer hits your "ticket granting service", gets a ticket, and then uses it the way they normally would

Thanks for your response and advice, Russell. And yes, that _is_exactly what I'm doing. : )

Would have been nice had our Tableau Professional Services consultant told us this. Not happy...yet another auxiliary server I have to install and set up to make Tableau work. Is there an "off the shelf" ticket granting web service available somewhere?

The main issue with this approach is as follows. To keep things simple, lets say you only have three users to deal with: Russell, Thom, and David. They login to Tableau Server via their browsers exclusively from the following IPs:

Russell: 192.168.1.1

Thom: 134.0.0.26

David 10.32.195.6

If you trust all three of these, then I can certainly generate a ticket for myself (Russell). However, I can just as easily create a ticket for Thom or David, or anyone else on the server. Not good

Since everyone's needs around a ticket granting service are different there aren't really any "off the shelf" versions. It's pretty easy to write one, though.

Seems like I have stepped into yet another of those critical, yet undocumented, areas of Tableau Server administration. I appreciate your pointing these things out to me, so please don't take any of my tone or criticisms personally.

Let me run this by you: I have multiple sites for disparate institutions who will be using this server for their individual needs, BI, research presentations, etc. Granted each of these institutions, coming from their trusted IPs can grant a ticket to any user from any other institution's site users. So if Institution A wants to protect certain content to only be visible to Bob, then Institution B (from its trusted server IP) can get a trusted ticket for Bob and see all of Institution A's protected content viewable by Bob, correct? So, although my intent is to give each institution its own "private" space, all I need to to is find the username of one person on Site A and use it in a trusted ticket request from my IP intended for use by Site B.

Is this also the case with Public Premium? My institutions have a reasonable expectation that their content will not be viewable by other institutions, but I obviously can't enforce anything via Tableau Server to that effect, if I'm interpreting your comments correctly. Please correct me if I'm wrong. So, in reality, "trusted" tickets as implemented in Tableau Server are not really trustworthy?

If you have documentation on the trusted ticket server, then please pass that along to me. I need to get started on this a.s.a.p.

Granted each of these institutions, coming from their trusted IPs can grant a ticket to any user from any other institution's site users. So if Institution A wants to protect certain content to only be visible to Bob, then Institution B (from its trusted server IP) can get a trusted ticket for Bob and see all of Institution A's protected content viewable by Bob, correct? So, although my intent is to give each institution its own "private" space, all I need to to is find the username of one person on Site A and use it in a trusted ticket request from my IP intended for use by Site B.

Correct, but you're coming at this from the wrong angle. Are these institutions really "trusted"? Do you trust them to do the right thing on your server? No, not really. Therefore, they shouldn't have the ability to request tickets themselves.

The only person you can trust is you. Therefore you should have the web service in play that you are in complete control - it is your "security guard". You let the institutions talk to the security guard, and he gives them a pass, or not...and that pass is limited to an area of the building, etc. etc...

Is this also the case with Public Premium? My institutions have a reasonable expectation that their content will not be viewable by other institutions, but I obviously can't enforce anything via Tableau Server to that effect, if I'm interpreting your comments correctly. Please correct me if I'm wrong. So, in reality, "trusted" tickets as implemented in Tableau Server are not really trustworthy?

Public Premium is a completely different animal. It doesn't use trusted tickets at all, there are no sites, groups, etc. for you to manage. Realistically, it won't work for you.

Your original approach was the right direction to move in - you just got off track a bit by allowing the institutions to request tickets themselves. Fix that, and you're golden.

Your above statement about Institution A being able to access Institute B is correct. The best approach I can think of would be to manage the authentication yourself and programmatically allow or restrict access.

This how I predict the flow would happen:

1. Institution submits username to a web service that you are hosting. This web service will be the only trusted IP

2. Web Service cross references the username being requested with a list of users in a database and the allowed IP addresses of that specific institution.

3. If it comes back with a match then your web service requests a ticket from Tableau Server and returns it to the institution's web portal.

4. The web portal then uses that ticket when requesting a visualization

(You will need to make sure client IP matching is turned off)

You could leverage Tableau's postgres for Site users along with your Institution/IP's list and manage that all from a light weight database.

Well, Russell, this is a whole nutha ball of wax that we hadn't counted on and was not at all addressed by our official Tableau consultant who was fully aware of our intentions with this server. I imagine my boss and others who signed the PO on this purchase will have a few choice words with Tableau. Meanwhile, I have to figure out how to make things work. :-\

So, it seems as though I'm going to need to access user and site information from the postgreSQL database. Is there documentation available for that anywhere, or do I need to reverse engineer?

Thanks for your help on this. I'd hate like **** to be finding out about this six months from now. Also thanks to Aaron Clancy for his input.

IF the answer is yes, this wouldn't be supported by Tableau and Support would probably make you rip those changes out when/if you have problems. You'd also be working with a security mechanism that hasn't been suggested to penetration testing, etc...(which would personally make me very uncomfortable as the guy who implemented it if I were in your shoes)

Well, although I don't like the fact that Site A can request a trusted ticket for a Site B user, the main issue from my perspective is that they can use it to pull content from Site A. I think a Location directive to allow only Site A IPs to pull Site A content with a trusted ticket request might work. In other words, don't let a Site B IP receive content from Site A on a trusted ticket request.

As for a "Tableau Supported" solution to this problem: I appreciate your input and fully respect your knowledge of the product, but the solution you have pointed out to me seems rather grey-zone in terms of officially supported Tableau Server admin practice. The data dictionary linked post totally waives off any inferences that this is endorsed at any level by Tableau. If I go this route, then I also have to worry about Tableau modifying its database and breaking my server. In that scenario, since Tableau doesn't share this proprietary information, I would be forced to reverse engineer the postgreSQL database. To me, the difference between this and modifying the Apache config seems moot. However, with an Apache directive I don't have to maintain a whole other server (and worry about its security, vulnerability monitoring, patches, updates). Either way, I am dealt a pain that I wasn't previously expecting to deal with, but I can feel somewhat assured that Apache directive syntax is less likely to undergo major changes than is Tableau's proprietary database. And with Apache being open source, I will always have free access to that information.

Regardless, this is a serious design flaw on Tableau's part, IMO, along with its inane uninstall/reinstall method for updating the server software. I'm still shaking my head on that one.

Thanks for your help. You have alerted me to this serious problem and once again, I thank you. I hope you can influence Tableau to in some way address this issue in future upgrades.

Your call, but there is a big difference between querying views that the product team put there for that purpose and actively changing the way our web server behaves.

Since I've been working with Server, the product team has only changed these views when new functionality is added to the product (for example, adding new fields to indicate which site a user is a member of when "sites" became a feature"). They are widely used by the Tableau community. You can do no "damage" to Tableau Server by hitting these tables.

By playing with the httpd.conf, you are actively changing the way the product behaves at a very fundamental level - you are modifying the way we handle web traffic in a way that no one has tested. If and when you have a problem, I can guarantee that support will make you demonstrate the issue on a "virgin" system without these mods.

I see this approach introducing much more risk into the equation than the design pattern that has already been discussed. It's a well known and lots of our customers (mostly SaaS vendors who embed Tableau) use it.

Russell brought this thread to my attention because of his concern for apache mods.

He's right. Apache mods are very risky, but tempting since it's an open technology that a certain population is extremely comfortable with. The catch here is that our Apache is highly customized to perform very specific tasks under very specific assumptions so that our code will execute against it in a predictable way. One critical assumption is that no one will make any changes that are not documented and recommended by Tableau Software for your particular situation.

If your integration against our Postgres DB fails due to a schema modification, it is likely we can work out the solution in the forums or via Tableau Support. Hopefully such an exercise is undergone inside your QA environment prior to production changes.