7 Replies Latest reply on Oct 7, 2015 1:15 PM by Travis Backs

    Tableau Server Permissions - a gap or by design?

    kyle.vasatka

      I'm waiting for confetti to fly after I hit "Post" because I think it may be the one millionth question about Tableau Server permissions.  I did some digging for previous posts and wasn't able to find one that answered this question unequivocally:

       

      I have a workbook in a "public" folder where the group All Users is allowed to do everything except Web Edit and Delete.  This workbook contains views which connect to a data source in a project where access is limited to a specific group.

       

      However, when a regular user in the All Users groups runs the report, he/she is able to do so successfully even though that user is not explicitly (or implicitly) granted rights to the secure project or the data source contained within the secure project.

       

      A few people on the forums have hypothesized that this is possible because the user has "Connect" rights to the folder that contains the workbook, even though that user has zero rights to the project containing the data source or to the data source itself.

       

      Basically, I want to verify whether the pattern that I am seeing is a gap in Tableau's permissions management or by design.

        • 1. Re: Tableau Server Permissions - a gap or by design?
          Matt Coles

          I find it helpful to think of Project (folder) permissions as "suggested" permissions that only apply to the Tableau Desktop publishing dialog box (when it comes to access permissions for datasources and workbooks, anyway). Content owners are under no restrictions to follow them. They can disregard those suggested permissions entirely.

           

          But yes--if a workbook is connecting live to a published data source on Tableau Server, and a user does NOT have group-based or individual permissions granting them access to that datasource, the only way they should be seeing that data is if they've been granted Connect rights on the View level (and this only on 8.3 or earlier, I believe--that feature was pretty confusing for the exact reason you posted).

          2 of 2 people found this helpful
          • 2. Re: Tableau Server Permissions - a gap or by design?
            kyle.vasatka

            Thanks for the reply Matt.

             

            That's the rub though...we're on 9.0.6 and seeing the pattern.  I can literally log in as a test user that has no specified access to the data source (or the project it contains) and run the public report and get results without any issue.

             

            Prior to this strange occurrence I would have said that I understand Tableau's permissions 100% but now I'm not so sure.

             

            What I would expect to see happen is that the user would see the report, attempt to run it, and be met with a message that he/she does not have rights to the data source.  But, that isn't happening.

             

            I would encourage anyone who is interested in understanding more about this issue to attempt to replicate it.  Maybe something just went haywire in my situation...

            • 3. Re: Tableau Server Permissions - a gap or by design?
              Donna Coles

              HI Kyle.  we had something today that may shed some light.

              We have data sources that are stored in a project which only a limited no of people have rights to connect to. The data sources are Tableau server extracts that connect live to a SQL database.  The users with connect rights on the datasource create workbooks and publish them to other projects which all users have rights on.  We have found that any user can then view the workbook and the data within, but get access denied type errors if they try to view underlying data or edit the workbook online.  This we assumed to be expected behaviour and instructed users that if the whole workbook needed to be secured they should publish to an alternative project and apply custom permissions. We first found this running v8.3 and are now on v9.0.3.

               

              Today we had reports of some users no longer being able to access a workbook that was set up like this, that they'd previously used. However they could still access other workbooks set up in the same way.  I figured it had to be something to do with the permissions on the data source being used, but couldn't initially understand why there was a difference with 2 workbooks doing pretty much the same thing.

               

              I republished the workbook that was failing making no changes, to the same location as before and it worked.  I believe the problem was due to the permissions on the secured data source in relation to the owner of the workbook.  The owner of the workbook that was failing has recently left and so no longer had permissions to the secured datasource it was using.  The other workbook that had always been working was owned by someone who had rights on secured datasource.  I have rights on the data source, so the republishing made it work.

               

              CHecking the authentication properties on the workbook at the point of publication, the credentials on the secured data source were set to embedded password. 

               

              So my theory is that the access to the secured data source is being determined by the owner who published the report when it's set to embedded credentials.  If the owner doesn't have access but the viewer happens to, they can get in.  If the owner doesn't have access and the viewer doesn't then a login prompt will appear.

               

              I suspect the owner of your workbook has access to the datasource (connect rights) otherwise they wouldn't have been able to write the report, and credentials are embedded.  I can't recall off the top of my head whether you might have an option to set the credentials to 'prompt user' which would then possibly force login.

               

              phew! Hope that helps.  Like I say not sure if it should be doing all that in the first place, but it's what we've observed.

              Donna

              2 of 2 people found this helpful
              • 4. Re: Tableau Server Permissions - a gap or by design?
                kyle.vasatka

                This is interesting because the issues do seem to coincide with a mass ownership transfer we did as part of a SAML roll-out.  Prior to SAML, we had users publishing and "owning" Tableau Server content under stand-alone accounts but subsequently did a series of mass transfers of ownership.

                 

                If it exists, I'm curious if/how Tableau communicates this dependency and at what point workbook ownership gets mixed in with user permissions.  I wouldn't think administrators would intuitively think about the impact to permissions when transferring ownership of Tableau Server content.  Very confusing.

                 

                In any event, your scenario makes complete sense to me and actually lines up with what I'm seeing!

                 

                I'm still struggling to see big picture how an administrator can flat out guarantee that User A or Group A can see certain content if what Tableau Server is showing in its permissions UI is incorrect or misleading.  To me, "republish and see if it fixes it" is the Tableau equivalent of "deleting your temporary internet files". 

                • 5. Re: Tableau Server Permissions - a gap or by design?
                  Matt Coles

                  Yep, after reading Donna's response I realized that that's how I've been granting others access to my datasources when they don't have explicit connect permissions. Totally forgot about that! Thanks for sharing, Donna!

                  • 6. Re: Tableau Server Permissions - a gap or by design?
                    Donna Coles

                    No worries. Glad my essay made sense :-)

                     

                    The more I think about it, I think this must be by design. It allows users to share summary views on data that is sensitive at a more granular level.

                     

                    For example we have expenses data in a secured data source.  It's at 1 row per expense line, so has details of the claimant, what it was spent on, how much etc.  At a high level seeing the total value of expense claims by division may be deemed an acceptable summarised level of data that anyone can see.  So this can be built in a workbook shared into a place anyone in the business can access. But having the ability to view the underlying data at a per user level is forbidden, hence the users can't connect to the data source directly or view underlying data etc unless they've been explicitly granted connect rights on that secure data source.

                    • 7. Re: Tableau Server Permissions - a gap or by design?
                      Travis Backs

                      I have a quick question with regards to this: We had a Tableau contractor just leave and ownership has not been transferred as of yet because we are unsure in changing ownership would invalidate saved views that other users may have created against these workbooks. People around here don't like change.