7 Replies Latest reply on Oct 15, 2015 5:49 PM by Michael Dowling

    Trusted Ticket Oddities

    Michael Dowling

      Hi All,

       

      I was hoping for some expert knowledge to help verify a potential issue I'm experiencing and also to answer a question around trusted tickets.

       

      I'm using Tableau Server 9.1.

       

      I'll start with the question since it's the easiest

      Question: When setting up trusted ticket whitelist IP's is there any way to restrict those IP's to a specific site. i.e. a ticket requested by 205.201.x.x can only access 'site1' in Tableau & a trusted ticket requested by 204.200.x.x can only access 'site2'?

       

      We've got some concerns with trusted ticket potential security holes for our implementation.

       

      Now for the weirdness I've experienced with Trusted Tickets that are a little concerning.

       

      The Oddities:

      I’ve created a little POC where I’m pulling in 1 report.

       

      • Step 1: load up the page without calling the trusted ticket server just pulling in the workbook – login page displayed (expected)
      • Step 2: put code in to call trusted ticket endpoint with username/site that has the report, get back the results and put that in the javascript api – workbook displayed (expected)
      • Step 3: remove the code to call the trusted ticket and don’t put anything in the javascript api call – workbook displayed (unexpected)
      • Step 4: Go to our tableau server – login displayed (expected)
      • Step 5: put in a different workbook with no trusted ticket – workbook displayed (unexpected)
      • Step 6: put in a different workbook for a different site that the user doesn’t have access too – workbook displayed (unexpected)

       

      Is there something that I’m missing? It’s like the initial call to the trusted ticket endpoint somehow logged me in and gave me access to everything.


      The code that I'm using to include the workbooks is:


      <script type='text/javascript' src='https://rpt-tst.cloudapp.net/javascripts/api/viz_v1.js'></script>

          <div class='tableauPlaceholder' style='width: 1353px; height: 614px;'>

              <object class='tableauViz' width='1353' height='614' style='display: none;'>

                  <param name='host_url' value='https%3A%2F%2Frpt-tst.cloudapp.net%2F'/>

                  <param name='site_root' value='&#47;t&#47;iCare_ScalabriniJune2019'/>

                  <param name='ticket' value='ticketfromserver' />

                  <param name='name' value='IncidentsByLocation&#47;Incidents' />

                  <param name='tabs' value='yes'/>

                  <param name='toolbar' value='yes'/>

                  <param name='showVizHome' value='n'/>

                  <param name='showShareOptions' value='true'/>

              </object>

          </div>


      And:


      <script type='text/javascript' src='https://rpt-tst.cloudapp.net/javascripts/api/viz_v1.js'></script>

          <div class='tableauPlaceholder' style='width: 1353px; height: 614px;'>

              <object class='tableauViz' width='1353' height='614' style='display: none;'>

                  <param name='host_url' value='https%3A%2F%2Frpt-tst.cloudapp.net%2F'/>

                  <param name='site_root' value='&#47;t&#47;iCare_ScalabriniJune2019'/>

                  <param name='name' value='IncidentsByLocation&#47;Incidents' />

                  <param name='tabs' value='yes'/>

                  <param name='toolbar' value='yes'/>

                  <param name='showVizHome' value='n'/>

                  <param name='showShareOptions' value='true'/>

              </object>

          </div>

        • 1. Re: Trusted Ticket Oddities

          Hey Michael,

           

          I've moved this post over to the Server Admin section of the Community where you are more likely to recieve a helpful response.

           

          Thanks for posting,

           

          -Diego

          • 2. Re: Trusted Ticket Oddities
            Jeff D

            Hi Michael,

             

            The behavior you're seeing is expected.  When you redeem a trusted ticket, you're actually creating a session (your browser will receive a session cookie from Tableau Server).  The session is limited in what can be done, but as long as you're displaying views that are accessible by the user, you'll see the behavior you've observed.

             

            Regarding your question about site restrictions, I don't know if there's a way to do this.  You'll need to set up your permissions by users and sites, not by ip addresses.

             

             

            BTW, if you have several issues, it's helpful to post different topics for each one.  It makes it easier when there are follow-on discussions, and it makes it easier for people trying to locate answers to similar questions.

            • 3. Re: Trusted Ticket Oddities
              Michael Dowling

              Hi Jeff,

               

              Thanks for the response in relation to how it works behind the scenes, that was what I needed. The thing that was concerning for me was that I was able to see things in different sites but that was actually due to the default upload permissions being guest can view so they were actually publically accessible which I did not expect and found quite strange.

               

              Regarding the site restrictions that's actually quite a large security concern and a potential blocker to us using trusted tickets. Permissions for users and sites is obviously what we are doing and we are restricting access based on that. The problem comes though when you allow trusted tickets to be generated based entirely on a username and site. Take the example:

               

              Users           Site Access

              User1           Site1

              User2           Site1

              User3           Site2

              User4           Site3

               

              You've opened up trusted tickets to be generated to 3 IP addresses (1 at each of the clients sites). If you can't limit each of those IP address that you've allowed to a particular site then anyone from any of those sites could generate a ticket to view data on any of the other users sites if they were to guess the username & site id combination. So User4 at Site2 could do a http post to create a ticket passing in User1 & Site1 and theoretically get access to any of the workbooks that User1 has access to.

               

              Does that make sense?

               

              Does anyone have any suggestions or setup to alleviate these concerns?

               

              Thanks,

              Michael

              • 4. Re: Trusted Ticket Oddities
                Jeff D

                Hi Michael,

                 

                The purpose of a trusted ticket is to allow your server to do its own authentication.  If User4 can pretend to be User1, then that authentication is not working.

                 

                So User4 at Site2 could do a http post to create a ticket passing in User1 & Site1

                 

                 

                It sounds as if User4 is directly contacting Tableau Server asking for a ticket.  If so, this means you're missing the authentication step.  User4 should be contacting your server (not Tableau) when a ticket is needed.  Your server should authenticate the user, do an http post to create a ticket for that user (and site), and return the ticket to the user (typically inside a web page).

                 

                Here's a diagram from the online help: http://onlinehelp.tableau.com/current/server/en-us/trusted_auth_how.htm

                • 5. Re: Trusted Ticket Oddities
                  Michael Dowling

                  Hi Jeff,

                   

                  We are not missing a authentication step, you are only thinking of valid and legitimate scenarios. We will be authenticating and doing our own validation and only doing requests from our webserver correctly controlling access and authentication.

                   

                  The point that I am raising is anyone with access to that WebServer (sysadmin or someone that gains access to that WebServer by malicious activity for example) can technically make that http post to the Tableau Server and gain access to any of our clients visualisations.

                   

                  This is further increased when you consider anyone within a on premise installation where the WebServer and clients exit through a single NAT address and obviously have the same external IP. So we would need to expose that single IP address to allow trusted authentication the outcome of this is anyone within that network (or again anyway that can gain access either legitimate through VPN or otherwise) can make the http post and impersonate the WebServer and hence gain access to ANY of the reports on ANY of the sites within Tableau.

                   

                  By restricting a Whitelisted IP to a specific site you greatly reduce the footprint of this hole.

                   

                  Can you please confirm the above scenarios and how we might mitigate any risk associated with these.

                   

                  Thanks,

                  Michael

                  • 6. Re: Trusted Ticket Oddities
                    Jeff D

                    The point that I am raising is anyone with access to that WebServer (sysadmin or someone that gains access to that WebServer by malicious activity for example) can technically make that http post to the Tableau Server and gain access to any of our clients visualisations.

                     

                     

                    The WebServer needs to be secured, just like Tableau Server needs to be secured.  If you don't trust your sysadmin, then you've got a problem.

                     

                    Your point about someone gaining access to the WebServer by malicious activity is an interesting one.  Tableau Server does not require the Web server to authenticate, it simply trusts requests coming from any process on the configured IP addresses.  Consider posting this in the Ideas forum.

                     

                    This is further increased when you consider anyone within a on premise installation where the WebServer and clients exit through a single NAT address and obviously have the same external IP. So we would need to expose that single IP address to allow trusted authentication the outcome of this is anyone within that network (or again anyway that can gain access either legitimate through VPN or otherwise) can make the http post and impersonate the WebServer and hence gain access to ANY of the reports on ANY of the sites within Tableau.

                     

                    Now I understand your original concern.  Reading through the documentation for Trusted Tickets, this scenario is clearly not supported. Even IP filtering (if supported) wouldn't be a complete solution, as it would still allow any user at one particular installation (with a single NAT address) to impersonate any other user at that installation (your comment is correct, it would reduce the footprint of the hole, but it wouldn't close it).  Even if there was a workaround that addressed all these issues, you'd have to find a way to secure the physically remote machine.

                     

                    Assuming you're able to secure your remote server, a possible workaround is to create a secure tunnel from the WebServer to the Tableau Server, effectively placing both servers on the same network.

                    • 7. Re: Trusted Ticket Oddities
                      Michael Dowling

                      Hi Jeff,

                       

                      Thank you for the response. I thought that was the case so this just confirms that we don't think it's going to be good enough for our scenarios.

                       

                      I'd argue that you can trust any sysadmin you want, but people do occasionally go rouge which is certainly a problem! The thing with our scenarios though is that it's not just us trusting one sysadmin - its us trusting n number of sysadmins, and each of our clients trusting n number of other clients sysadmins.

                       

                      I'll document this scenario up for the team so we can do risk assessment.

                       

                      Thank you for your time.

                       

                      Michael