11 June 2014
Tableau has a robust security model which can seem complex to understand, so let's take a look at permissions in detail and some of the common problems people have.
What first confuses people looking at Tableau administration for the first time is the number of areas where permissions can apparently be set, there are six in total: Site, Project, Group, User, Workbook and Data Source and to understand how Tableau permissions work it is crucial to understand those different levels and how they interact.SitesSites are the top level of user security and are typically used to create different environment for users; each site is administered separately and has its own Groups, Users, Projects, Workbooks and Data Sources. A user with access to only some sites on a server will not be able to access resources on the other sites, nor will they be able to login or view any information on the sites they do not have access to - note the difference in the Admin panel between 'All Users' and 'Site Users'. If a user has access to more than one site they will be prompted to choose which site they want to enter when they login to the server. Immediately after installation a single Site will exist called 'Default', this can be renamed but cannot be deleted as a Server must always have at least one Site.ProjectsProjects are also used to separate content in the server, but, as they share Groups and Users with the other Projects in the site, this is typically as a way to split the content into functional areas. e.g. you may have Tableau users in Finance, Marketing, Sales and IT and wish to serve different content to each team - Projects provide an ideal way of doing this. Immediately after installation a single Project will exist in the Default Site called 'Default', this cannot be renamed and cannot be deleted as a Site must always have a default Project.Access to a Project is granted by the permissions set on that Project, each Group andor User can be assigned a set of permissions (see here) within the Project determining what, by default, they can or can't do with workbooks published to that Project.GroupsGroups are collections of Users and group up a Site's Users into manageable sets for administration purposes. Groups can either be manually created or synced from an Active Directory if available. Each Site has at least one Group called 'All Users' - which, as the name suggests, is a set of all the Users on a Site.UsersUsers are the individual named users accessing a Site, all users on Tableau Server must be assigned a license level, even if they are Unlicensed (see here). Each User can additionally be given two user rights: Publish and Administrator; when setting a user as administrator you will be asked to choose whether they are a System Admin (and so can administer all Sites and permissions) or Site Admin (whose rights are just for the given Site).One of the most common questions we get is regarding User and Group permissions that allow a User different access, who wins? Well firstly User takes precedence over Group, and Deny take precedence over Allow. As per the digram below:
Note the end point of 'Denied' - unless a permission is explicitly granted it will be denied.WorkbooksHaving set up the above then it is when publishing individual workbooks that the rights of users to access the workbook on the Server gets decided. This is the first, and most important, thing in understanding Tableau permissions: The person publishing the dashboard controls who sees their data when it is published. They can choose a Project, which will set defaults for the different Users and Groups based on its settings, but then they can add other Site Users and change the permissions of GroupsUsers as they see fit.
NB. Permissions can also be set at a view level once the workbook is published but this leads to a very complex security structure and is to be avoided if at all possible.Data SourcesSimilar to Workbooks Data Source permissions are also determined by the Publisher.What this meansEffectively this means that regardless of what Projects, Users and Groups you set as an administrator the Desktop users are the ones that control the access to the visualisations they produce. Still not sure? The Tableau Administrator Guide describes it well:
Best PracticeSo what would I recommend as a best practice process for setting up Tableau Server security? The honest answer here is 'it depends' but the outline below details how I might start advising a client.Create a group for AdminsAdministering administrators is a lot easier if you set up a group, remember AD Groups won't sync automatically but you can use tabcmd to automate the create and addition of rights to this group. This will allow you to add and remove users from the admin role as necessary.Brainstorm your Security ModelGather a collection of desktop users and also some stakeholders, discuss the dashboards that are in mind and the typical use cases. Try and answer some of the following questions and use the Permissions Reference to discuss what types of user you have:- Are we visualising sensitive data that needs to be controlled via special sites?- Who needs rights to publish? What about editing other users dashboards?- What viewer roles do we have? Are all viewers the same with regard permissions?- What Projects will be required, how will Publishing and Viewing differ per Project?- Are there any people who will always have a role regardless of Project?Out of this brainstorm should come a good view of what permissions are needed, keep it simple as you can always add complexity later - it's harder to remove complexity once you've gone down a certain path.Inheriting PermissionsIf you're going to use the 'Inherit' permission option then have a plan, 'Inherit' (used instead of Allow or Deny) can get very confusing if you don't know what's being inherited but used in the right way you can get a lot of value from it, take this tip from the Server Permissions document (see Further Reading below):
What first confuses people looking at Tableau administration for the first time is the number of areas where permissions can apparently be set, there are six in total: Site, Project, Group, User, Workbook and Data Source and to understand how Tableau permissions work it is crucial to understand those different levels and how they interact.SitesSites are the top level of user security and are typically used to create different environment for users; each site is administered separately and has its own Groups, Users, Projects, Workbooks and Data Sources. A user with access to only some sites on a server will not be able to access resources on the other sites, nor will they be able to login or view any information on the sites they do not have access to - note the difference in the Admin panel between 'All Users' and 'Site Users'. If a user has access to more than one site they will be prompted to choose which site they want to enter when they login to the server. Immediately after installation a single Site will exist called 'Default', this can be renamed but cannot be deleted as a Server must always have at least one Site.ProjectsProjects are also used to separate content in the server, but, as they share Groups and Users with the other Projects in the site, this is typically as a way to split the content into functional areas. e.g. you may have Tableau users in Finance, Marketing, Sales and IT and wish to serve different content to each team - Projects provide an ideal way of doing this. Immediately after installation a single Project will exist in the Default Site called 'Default', this cannot be renamed and cannot be deleted as a Site must always have a default Project.Access to a Project is granted by the permissions set on that Project, each Group andor User can be assigned a set of permissions (see here) within the Project determining what, by default, they can or can't do with workbooks published to that Project.GroupsGroups are collections of Users and group up a Site's Users into manageable sets for administration purposes. Groups can either be manually created or synced from an Active Directory if available. Each Site has at least one Group called 'All Users' - which, as the name suggests, is a set of all the Users on a Site.UsersUsers are the individual named users accessing a Site, all users on Tableau Server must be assigned a license level, even if they are Unlicensed (see here). Each User can additionally be given two user rights: Publish and Administrator; when setting a user as administrator you will be asked to choose whether they are a System Admin (and so can administer all Sites and permissions) or Site Admin (whose rights are just for the given Site).One of the most common questions we get is regarding User and Group permissions that allow a User different access, who wins? Well firstly User takes precedence over Group, and Deny take precedence over Allow. As per the digram below:Note the end point of 'Denied' - unless a permission is explicitly granted it will be denied.WorkbooksHaving set up the above then it is when publishing individual workbooks that the rights of users to access the workbook on the Server gets decided. This is the first, and most important, thing in understanding Tableau permissions: The person publishing the dashboard controls who sees their data when it is published. They can choose a Project, which will set defaults for the different Users and Groups based on its settings, but then they can add other Site Users and change the permissions of GroupsUsers as they see fit.NB. Permissions can also be set at a view level once the workbook is published but this leads to a very complex security structure and is to be avoided if at all possible.Data SourcesSimilar to Workbooks Data Source permissions are also determined by the Publisher.What this meansEffectively this means that regardless of what Projects, Users and Groups you set as an administrator the Desktop users are the ones that control the access to the visualisations they produce. Still not sure? The Tableau Administrator Guide describes it well:The initial permissions for a project are copied from the Default project. The initial permissions for a workbook are copied from the permissions for its project. The initial permissions for a view are copied from the permissions of its workbook. This is a one-time copy of the parent’s permissions. Changes to the parent’s permissions are not automatically applied to the children unless the new permissions are actively assigned to the contents.Any item can have permissions that differ from the parent. For example, a group might not have permission to see Project X, but it may have permission to see a view that’s published to Project X. Tableau Server does not support hierarchical object permissions; however, it does provide an inheritance model for users and groups. If a user does not have a permission explicitly set to Allow or Deny, the setting will be inherited from the groups the user belongs to.Once you understand that then you can work with it, here are some tips:- as an administrator you should ensure the Projects, Users and Groups you set up give everything the user needs to quickly give permissions without resorting to customising each user's access on a workbook by workbook basis.- ensure Desktop users who will be publishing dashboards and / or data sources understand Tableau permissions and their responsibility in setting them.- limit the fields users can access in a Data Warehouse using views to stop the accidental publication of sensitive data, e.g. personal details such as name, salary, etc. Typically these won't need to be visualised and so there is no need for people to access them.- if some data is particularly sensitive and needs to be visualised by certain people then create Tableau Server Sites to limit who can see these visualisations.- system and site administrators can see all data and visualisations within the Server and Site respectively, so only give these roles to people who are entitled to see all the data.- in general you should avoid giving workbooks custom permissions as these could easily be accidentally (or deliberately) overwritten at the Project level by an administrator using the 'Assign Permissions to Contents'.
Best PracticeSo what would I recommend as a best practice process for setting up Tableau Server security? The honest answer here is 'it depends' but the outline below details how I might start advising a client.Create a group for AdminsAdministering administrators is a lot easier if you set up a group, remember AD Groups won't sync automatically but you can use tabcmd to automate the create and addition of rights to this group. This will allow you to add and remove users from the admin role as necessary.Brainstorm your Security ModelGather a collection of desktop users and also some stakeholders, discuss the dashboards that are in mind and the typical use cases. Try and answer some of the following questions and use the Permissions Reference to discuss what types of user you have:- Are we visualising sensitive data that needs to be controlled via special sites?- Who needs rights to publish? What about editing other users dashboards?- What viewer roles do we have? Are all viewers the same with regard permissions?- What Projects will be required, how will Publishing and Viewing differ per Project?- Are there any people who will always have a role regardless of Project?Out of this brainstorm should come a good view of what permissions are needed, keep it simple as you can always add complexity later - it's harder to remove complexity once you've gone down a certain path.Inheriting PermissionsIf you're going to use the 'Inherit' permission option then have a plan, 'Inherit' (used instead of Allow or Deny) can get very confusing if you don't know what's being inherited but used in the right way you can get a lot of value from it, take this tip from the Server Permissions document (see Further Reading below):Use the “Default” project as a permissions template for all other projects. This is because all new projects will inherit permissions from this “default” project.This is perhaps one of the most important best-practice tips available. Tableau ships with a built-in project called “Default” that cannot be deleted. The shipping permission settings for this “default” project are to allow “all users” (a built-in group) some basic abilities to view content. You have options here.One option is to make the default project restrictive, and to explicitly deny all permissions. In this scenario, all new projects created will inherit this concept of “deny” from the default project – this could be useful for organizations that desire a locked down environment with “allowance” being the exception and not the rule. Another option is to make the default project interactive but read-only with no access to underlying data. By disabling “View Underlying Data” and “Download Workbook” for the default project, all new projects (and thus their content) will inherit these permissions – this could be useful for organizations that want to standardize on visualization access, while still restricting data and workbook access.A third option is simply to remove “all users” from the “default” group. This means any new projects created are truly a blank canvass from a security perspective – this option could be useful for organizations that do not have a standard in place, or those organizations where the standards change from project to project.These are choices, and your actual deployment can differ and be fully customized.Start SimpleCreate a group per role for a couple of projects, e.g. Project1_Publisher, Project2_Publisher, Project1_Viewer, Project2_Viewer, AllProjects_Viewer and set the permissions for the Groups in the Project accordingly. Use a UAT period to test the permissions work and review before launching a live project.Discourage Custom PermissionsWe've mentioned it already but we'd really encourage against setting custom permissions when publishing, if this is essential then make a separate secure Site where users can publish their dashboards and feel confident their permissions won't get overwritten later as changes are pushed down at the Project level.Use the Guest Account to spread Tableau LoveIf you have a core licence you can use the Guest Account to provide unlicensed users with sneak preview of Tableau to show off your best dashboards. People are bound to hear about Tableau from excited colleagues and may want to give it a try to see what all the fuss is about, so you might want some Help information and 'How to get access' dashboards too. Remember though that since people aren't logging in then only give the Guest Account access to a limited number of non-sensitive views.Continual ReviewIf you're an administrator then don't allow permissions to become forgotten, educate users about the permissioning model and ensure new Tableau desktop users are given a brief induction as to their responsibilities. As a group ensure you find time to review the permission process - all to often users become disengaged if they feel there is no feedback mechanism to you as an administrator.Further ReadingWorking with Permissions - Tableau help has a comprehensive set of articles outlining permissions and the Tableau security model.Creating Project Based Permissions - This Tableau Knowledge Base article steps through the process of creating permissions for each project and broadly follows the best practice laid out above.Server Permissions - A great pdf on Cory Retherford's site, full of useful tips.Data Security - Understanding which users can access raw data via a live data source is important.Row level Security and User Filters - Again, not a subject we've touched on above but well worth understanding the potential here. Watch this space for a blog post soon.Want More?Remember that Tableau listen to your ideas, if you'd like extra features for security why not vote for or add ideas to the Tableau Community.Thanks for reading, any comments welcomed.