4 February 2016
This is an update to the excellent blog post written by Chris Love on Tableau Server permissions. Some concepts in the Tableau Server permissions model have changed in version 9 and version 9.2, so let’s revisit Chris’s post to understand how permissions work now....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 at the top of the content hierarchy, and provide a way to partition your server into separate environments for users. Each site is administered separately and has its own Groups, Users, Projects, Workbooks and Data Sources. Immediately after installation a single Site will exist – the “Default” site. This site can be renamed but cannot be deleted as a Server must always have at least one Site.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. What you see and how you can control users and content on different sites depends on your permissions, and whether you have more than one site enabled on your server.Here’s an excerpt from the Tableau Server User guide:'In a multi-site deployment, click the Server menu to control server-wide settings that you will use to configure, monitor, and maintain Tableau Server. As the server administrator, only you can access Server pages for status, sites, Server Users, schedules, tasks, and any settings that apply to the server as a whole. For single-site deployments, all of your server and site-related menus will be available without the Server menu.'On a multi-site server, these are the Site menus a server administrator sees.
On a multi-site server, these are the Server menus a server administrator sees. 
On a single-site server, these are the menus a server administrator sees. To create a site, click the Settings menu. 
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.ProjectsProjects are the next level down in the content hierarchy. Projects exist within Sites, and are also used to separate content in the server. They can be thought of in much the same way as folders in an operating system file structure, e.g. Windows folders. Since projects share Groups and Users with the other Projects in the site, this is typically a way to split your content into logical groupings, for example around department, function, author, or even SDLC environment. For example, you may have Tableau users in Finance, Marketing, Sales and IT and wish to serve different content to each team, controlling access to each set of content accordingly; 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.A newly created project will take its permissions from the permissions set on the Default project in that site. Note: the default permissions for the default project is to allow all users access – my recommendation is to always remove all permissions from the default project immediately after installation, so any newly created projects start with no permissions until you explicitly add them.GroupsGroups are collections of Users within a site. They help to organise and manage sets of users for administration purposes. Groups can either be manually created or imported from an Active Directory (and kept in sync), 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. Every user added to Tableau Server must have an associated site role, these roles are described in the image below. 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.
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 diagram below:
Note the end point of “Denied” – unless a permission is explicitly granted it will be denied. WorkbooksNew workbooks and data sources use the default permissions from their project. When content permissions are not locked, the individual workbook and data source permissions can be edited to differ from the defaults. This is the first, and most important, thing in understanding Tableau permissions: Unless permissions are locked, the publisher of the dashboard has final control over who sees their data when it is published. You’ll see above we talked about the concept of locking permissions. This is a brand new feature in v9.2 and as an administrator or project leader, you can prevent users from changing the permissions for workbooks and data sources in a project. To do so, you can lock content permissions for that project.Taking an excerpt from the Tableau Server user guide:“When permissions are locked to the project, the default permission settings are applied to all workbooks, views, and data sources in a project and cannot be modified by users (including content owners). When permissions are managed by the owner ('unlocked'), content permissions remain the same as when the project was locked, but the permissions become editable.”
Publishers will see the difference between a locked and unlocked project when publishing content to Tableau Server from Tableau Desktop. Here is the publish dialog in Tableau Desktop for an unlocked project. Here, the user can customise the workbook permissions to their liking:
Here is what a locked project looks like in the publish dialog in Tableau Desktop. Here, the user has no control over the workbook permissions. Instead the workbook takes its permissions from the project:
Permissions can also be set at the individual view level, i.e. views within a workbook, 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 can be determined by either the Publisher, if publishing to an unlocked project, or by the project permissions, if publishing a data source to a locked project.So, how does all this play out? Well, once a user has been added to a site on the server, and granted a licensed site role, the effective user permissions for a resource, as described in the user guide, are determined by:
This will bring up a new window which shows you exactly which users and groups are allowed or denied access:
Edit these permissions by once again finding the three little dots next to the user or group name, and choose ‘edit’ from the menu. Note how if a group is selected, a list of all the users in that group appears in a table below, showing you each individual’s effective permissions for that content. Tips and recommendationsSo 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.1. Permission groups, not usersGranting individual users permissions to projects, or other content, gets messy quickly. More often that not you'll want to add/change/remove permissions for groups of users, rather than individuals. Even if only one person needs to access that content now, create a group anyway and grant permissions to the group, so that adding users later is simply a case of adding those people to the right group. It will save you a lot of headache in the long run.2. Create a group for AdminsAdministering administrators is a lot easier if you set up a group. You can do this by manually creating a group on Tableau Server, or setting a group up on Active Directory and importing that group instead. This will allow you to add and remove users from the admin role as necessary.3. Grant administrator access sparinglySystem 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.4. 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. 5. Remove all permissions from the default project immediately after installationThis will ensure newly created projects will start with zero permissions until you explicitly apply whichever default permissions you want on that project. 6. Start SimpleIf you’re still unsure about how to proceed, start by creating a group of users for each combination of role and project, e.g. Project1_Publisher, Project1_Interactor, Project2_Interactor, Project2_Publisher, AllProjects_Interactor etc., 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. 7. Apply additional security at the database layer for very sensitive informationLimit 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. These usually don’t need to be visualised and so there is no need for people to access them.8. Lock permissions on projectsLock the permissions on projects where access to content need to be rigidly controlled. Additionally, lock the permissions on projects that contain data sources. Typically, data sources need to be managed with a bit more control, and this will help prevent accidental deletion or overwriting of data sources by users.9. Create a sandbox where authors can publish without restrictionsMake sure your users have a space where they can freely publish and set the permissions they like. Set up a ‘playground’ or ‘sandbox’ project where permissions are not locked and allow users to publish and set their own permissions on ad-hoc content. As a Server Administrator however, you’ll want to keep an eye on this space, and perhaps set some ground rules, like not providing support for content published in this space. You might also want to create a policy of spring cleaning this space once a year or so, to ensure the space doesn’t get too clogged with dead content.10. Discourage custom permissions at workbook level or below We’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. 11. 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. 12. Continual ReviewIf you’re an administrator, then educate your users about the permissions 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 too 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.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 Tableau Server security why not vote for or add ideas to the Tableau Community, or discuss them on the Tableau Server Administration Forum.
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 at the top of the content hierarchy, and provide a way to partition your server into separate environments for users. Each site is administered separately and has its own Groups, Users, Projects, Workbooks and Data Sources. Immediately after installation a single Site will exist – the “Default” site. This site can be renamed but cannot be deleted as a Server must always have at least one Site.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. What you see and how you can control users and content on different sites depends on your permissions, and whether you have more than one site enabled on your server.Here’s an excerpt from the Tableau Server User guide:'In a multi-site deployment, click the Server menu to control server-wide settings that you will use to configure, monitor, and maintain Tableau Server. As the server administrator, only you can access Server pages for status, sites, Server Users, schedules, tasks, and any settings that apply to the server as a whole. For single-site deployments, all of your server and site-related menus will be available without the Server menu.'On a multi-site server, these are the Site menus a server administrator sees.On a multi-site server, these are the Server menus a server administrator sees. On a single-site server, these are the menus a server administrator sees. To create a site, click the Settings menu. 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.ProjectsProjects are the next level down in the content hierarchy. Projects exist within Sites, and are also used to separate content in the server. They can be thought of in much the same way as folders in an operating system file structure, e.g. Windows folders. Since projects share Groups and Users with the other Projects in the site, this is typically a way to split your content into logical groupings, for example around department, function, author, or even SDLC environment. For example, you may have Tableau users in Finance, Marketing, Sales and IT and wish to serve different content to each team, controlling access to each set of content accordingly; 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.A newly created project will take its permissions from the permissions set on the Default project in that site. Note: the default permissions for the default project is to allow all users access – my recommendation is to always remove all permissions from the default project immediately after installation, so any newly created projects start with no permissions until you explicitly add them.GroupsGroups are collections of Users within a site. They help to organise and manage sets of users for administration purposes. Groups can either be manually created or imported from an Active Directory (and kept in sync), 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. Every user added to Tableau Server must have an associated site role, these roles are described in the image below. 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.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 diagram below:Note the end point of “Denied” – unless a permission is explicitly granted it will be denied. WorkbooksNew workbooks and data sources use the default permissions from their project. When content permissions are not locked, the individual workbook and data source permissions can be edited to differ from the defaults. This is the first, and most important, thing in understanding Tableau permissions: Unless permissions are locked, the publisher of the dashboard has final control over who sees their data when it is published. You’ll see above we talked about the concept of locking permissions. This is a brand new feature in v9.2 and as an administrator or project leader, you can prevent users from changing the permissions for workbooks and data sources in a project. To do so, you can lock content permissions for that project.Taking an excerpt from the Tableau Server user guide:“When permissions are locked to the project, the default permission settings are applied to all workbooks, views, and data sources in a project and cannot be modified by users (including content owners). When permissions are managed by the owner ('unlocked'), content permissions remain the same as when the project was locked, but the permissions become editable.” Publishers will see the difference between a locked and unlocked project when publishing content to Tableau Server from Tableau Desktop. Here is the publish dialog in Tableau Desktop for an unlocked project. Here, the user can customise the workbook permissions to their liking:Here is what a locked project looks like in the publish dialog in Tableau Desktop. Here, the user has no control over the workbook permissions. Instead the workbook takes its permissions from the project:Permissions can also be set at the individual view level, i.e. views within a workbook, 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 can be determined by either the Publisher, if publishing to an unlocked project, or by the project permissions, if publishing a data source to a locked project.So, how does all this play out? Well, once a user has been added to a site on the server, and granted a licensed site role, the effective user permissions for a resource, as described in the user guide, are determined by:- The maximum capabilities allowed for a user's site role. The site role acts as the 'ceiling' for what permissions are allowed.
- Whether the user owns the content item – an author has full control over their published content.
- The evaluation of each user or group permission rule that applies to that user for that content item
This will bring up a new window which shows you exactly which users and groups are allowed or denied access: Edit these permissions by once again finding the three little dots next to the user or group name, and choose ‘edit’ from the menu. Note how if a group is selected, a list of all the users in that group appears in a table below, showing you each individual’s effective permissions for that content. Tips and recommendationsSo 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.1. Permission groups, not usersGranting individual users permissions to projects, or other content, gets messy quickly. More often that not you'll want to add/change/remove permissions for groups of users, rather than individuals. Even if only one person needs to access that content now, create a group anyway and grant permissions to the group, so that adding users later is simply a case of adding those people to the right group. It will save you a lot of headache in the long run.2. Create a group for AdminsAdministering administrators is a lot easier if you set up a group. You can do this by manually creating a group on Tableau Server, or setting a group up on Active Directory and importing that group instead. This will allow you to add and remove users from the admin role as necessary.3. Grant administrator access sparinglySystem 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.4. 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. 5. Remove all permissions from the default project immediately after installationThis will ensure newly created projects will start with zero permissions until you explicitly apply whichever default permissions you want on that project. 6. Start SimpleIf you’re still unsure about how to proceed, start by creating a group of users for each combination of role and project, e.g. Project1_Publisher, Project1_Interactor, Project2_Interactor, Project2_Publisher, AllProjects_Interactor etc., 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. 7. Apply additional security at the database layer for very sensitive informationLimit 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. These usually don’t need to be visualised and so there is no need for people to access them.8. Lock permissions on projectsLock the permissions on projects where access to content need to be rigidly controlled. Additionally, lock the permissions on projects that contain data sources. Typically, data sources need to be managed with a bit more control, and this will help prevent accidental deletion or overwriting of data sources by users.9. Create a sandbox where authors can publish without restrictionsMake sure your users have a space where they can freely publish and set the permissions they like. Set up a ‘playground’ or ‘sandbox’ project where permissions are not locked and allow users to publish and set their own permissions on ad-hoc content. As a Server Administrator however, you’ll want to keep an eye on this space, and perhaps set some ground rules, like not providing support for content published in this space. You might also want to create a policy of spring cleaning this space once a year or so, to ensure the space doesn’t get too clogged with dead content.10. Discourage custom permissions at workbook level or below We’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. 11. 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. 12. Continual ReviewIf you’re an administrator, then educate your users about the permissions 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 too 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.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 Tableau Server security why not vote for or add ideas to the Tableau Community, or discuss them on the Tableau Server Administration Forum.