In the previous two installments of this series we looked at self service and how we applied that at CACI. See here.
It’s now time to look at how we grant access to those users we carefully designed content for. Our deployment requires us to use a Portal which has a document library, newsletter management and an upload section as well. The way we manage our users is by using active directory.
The important aspect here is that we use active directory to create groups depending on function, within those groups we add the users that have access to different content within Tableau Server. This allows us to have a single sign-on even though the user is actually logged into two distinct applications, the portal which subsequently passes the credentials to Tableau Server. Here’s a good starting point to understanding the various options of authentication provided with Tableau Server.
We have defined that a user can only be a member of 1 site, which is controlled within the Portal integration. This is not a common step I don’t think, but as this is an external offering we have to be extra careful. This part is handled by the portal, if someone by mistake adds a user to two Site groups on AD, the system will trigger an error and the user does not have access to Tableau Server.
Before setting your user permissions, is paramount that you understand how Tableau organises permissions and that you map (on a whiteboard if needed) how you are going to manage the permissions and content access for your users. Do this right at the start of your Tableau Server deployment even if you only have 5 users. You’ll be glad you did when the news of a shinny Tableau Server being available spreads like wild fire within your organisation.
Other software companies have a different structure to Tableau in that the initial level of access is quite restrictive and the admin opens up the access as needed. Tableau is the opposite, see below how this works.
Here’s an example of how this would work in real life.
By this point you may be asking, why can’t I just give my users the access they need and be done with it? Or if I define permissions per workbook that will be fine too?
NO!! Please repeat after me. “I will never, ever, set permissions at user, workbook or data source level, I will never, ever, set permissions at user, workbook or data source level, I will never, ever, set permissions at user, workbook or data source level”.
For a number of reasons, the first being that you have no idea who will be publishing content in 6 months time and that even if you create an instructions sheet on the type of permissions to be set on the workbook, that no one will make a mistake. People often make mistakes. By defining the permissions at Site, Project and Group level, you are future proving your admin tasks and making the life of your users easier by not having to worry about permissions.
I’m sure Tableau would agree too, they released in 9.2 a featured called “Locked to Project” in which the site or server administrator(more on roles later), locks the permissions to a project taking the decision away when a user is publishing content. Follow the link to learn more about it.
At work what we’ve done was to:
Create a site per external organisation
Create a project per business area (savings, mortgages)
Create an AD group per business area as above
Add users to their respective group.
The way this works, if we have a user that has access to savings only, they can access the site and only see the project for savings, maybe a colleague of theirs works with mortgages too and was added to the mortgages AD group. When they log in the see two projects instead of the one seen by their colleagues.
Before we look into roles two things worth remembering:
New projects mirror the permissions of the default project which is seen by the Admin. To avoid mistakes, remove all permissions from the default project. Therefore when a new project is created it will have no permissions associated
All projects have a group called “All Users” remove all permissions from this group and use your defined groups to set permissions.
From Tableau’s Server Admin Guide:
“Site Roles for Users
Every user added to Tableau Server must have an associated site role. The site role is assigned by the administrator. The site role determines the levels of permissions allowed for a user, including whether a user can publish, interact with, or only view content published to the server. Administrators are also defined based on the site role.
Note: Tableau Server site roles do not correspond to user licenses that you purchase from Tableau (if you are using user-based licensing instead of core-based server licensing). Those licenses allow a certain number of users on the server.
Users are accounts on the server that can be associated with one or more sites, and with groups in those sites. Any user that is added to Tableau Server or to a site becomes member of the All Users group. The All Users group is present in every site and cannot be deleted.” page 218
These are the available roles within Tableau Server:
Server Administrator – Rules all
Site Administrator – Can manage users, groups content etc within a site
Publisher – Can publish content and interact with content previously published
Interactor – Can interact with content but is not allowed to publish
Viewer – can view dashboards but cannot filter or sort for instance
Unlicensed – no access
Viewer (can publish) – can publish via Tableau Desktop but can only view within Tableau Server
Unlicensed (can publish) – no access to Tableau Server but can publish from desktop
Sometimes you may want to create two groups within the same project similar to the example above, where one group is an Interactor and the other a Publisher. If each group has >10 people you can quickly see how difficult will be to manage it. If using groups however, we can quickly add a user to a group, sync in case of AD and the user has the correct permissions straight away.
In addition it is important to understand how permissions are evaluated, this is a resource I often went to when deciding how to set up our environment. “How Permissions are Evaluated”
Bear in mind that all these roles can be fine tuned by changing the permissions at each level:
By making judicious use of the permissions settings available to us in Tableau Server, we were able to set a robust and secured environment in which to onboard new users easily and to manage content access in a simple way.
If you have inherited a server where Tableau permissions were an afterthought you can start by downloading the “Tableau Permissions Bomb” a great workbook by Darth Flashypants which shows exactly who has what level of access using the PostgreSQL database from Tableau. See here for instructions and where to download the workbook.
Finally to close the post I have an idea I’d like to share with you.
I’m a big fan of the way Tableau grants access to content, the ability for the admin to control it and as you’ve been following in this series I like to be able to give our users the ability to create their own analysis not just consume pre-canned reports. We’ve been doing this successfully with Web Editing in the server but I’d like to provide even greater access to our users.However we can’t for legal reasons allow the user to download full data (see workbook image above). Currently, if a user is allowed to save (they need to be a Publisher) they can download full data. This makes perfect sense, because as the Tableau permissions work, a Publisher is an owner of the data source and can therefore download everything.
My suggestion would be to allow a user to save but give the option to the Server Admin whether to allow the user download full data or not.
If you think this is a good suggestion I’ve added it to the ideas forum to be up voted for consideration by the development team at Tableau. Vote here!
Thank you for reading, I hope the above is useful and here are a few people you should follow on twitter to understand a bit more about the way Tableau Server works.