2 of 2 people found this helpful
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).
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...
2 of 2 people found this helpful
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.
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".
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!
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.
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.