Restrict Access at the Data Row Level
When you share workbooks with others by publishing them to Tableau Server or Tableau Cloud, by default, all users who have access to the workbooks can see all of the data shown in the views. You can override this behaviour by applying a type of filter that allows you to specify which data “rows” any given person signed in to the server can see in the view.
This approach for securing data at the row level applies to data sources with live connections and extract data sources whose tables are stored as multiple tables. For more information about storing extract data using multiple tables, see Decide how the extract data should be stored.
Note: For information on the alternatives you can use to implement row-level security in Tableau, see an Overview of Row-Level Security Options in Tableau(Link opens in a new window) in the Tableau Server Help.
For additional related information, see the whitepaper Best Practices for Row_Level Security with Entitlement Tables(Link opens in a new window).
Suppose you created a quarterly sales report for a set of products over several years, in different geographic regions.
When you publish this report, you want to allow each regional manager to see only the data relevant to his or her region. Rather than creating a separate view for each manager, you can apply a user filter that restricts access to the data based on users’ characteristics, such as their role.
Restricting access to data in this way is referred to as row-level security (RLS). Tableau offers the following approaches to row-level security:
This method is convenient but high maintenance, and security can be tentative. It must be done per-workbook, and you must update the filter and republish the data source as your user base changes.
Using this method, you create a calculated field that automates the process of mapping users to data values. This method requires that the underlying data include the security information you want to use for filtering.
The most common way to do this is to use a reference (“look-up,” "entitlements," or "security") table that contains this information. For example, if you want to filter a view so that only supervisors can see it, the underlying data must be set up to include user names and specify each user’s role.
Because filtering is defined at the data level and automated by the calculated field, this method is more secure than mapping users to data values manually.
Adding user filters to data sources
The two methods in the previous section describe ways to add filters to data embedded in workbooks. If multiple workbooks connect to the same data, instead of wrangling filters on each workbook, you can filter the data source, and then connect the workbooks to the data source after you publish it.
Workbooks that connect to your filtered data source expose only the data the user signed in to the server is allowed to see. In addition, all connected workbooks show data refreshes as they occur.
Generally, when using one of the methods described above, RLS with extracts are faster to create and have better performance than RLS with data sources that use live connections.
As mentioned earlier, the first requirement to using RLS with extracts is that the data in the extract should be stored using multiple physical tables. You can configure your extract to have its data stored using multiple physical tables by following Decide how the extract data should be stored.
In addition to the above requirement, there are some additional considerations to make if you plan to use RLS with your extract. Because extract data stored using multiple tables do not support extract filters and some other functionality that help reduce the amount of data in the extract, you might consider using one of the following suggestions:
Connect to data using custom SQL
Connect to a database view that already has the appropriate level of filtering
For more information about these suggestions, see Alternative filtering suggestions when using the Physical Tables option.
Recommended practices for RLS with extract data sources
To effectively perform RLS with extracts, Tableau recommends keeping the number of tables (or database views or custom SQL queries) in your extracts to two. In other words, Tableau recommends that the tables in your extract be comprised of the following types of tables:
A data table – this is the "object" table that contains all the data you want to show.
A reference table – this is the "look-up" or "entitlements" table that contains the user information and the security groups the users belong to.
By minimising the tables in your extract to these two, you ensure that the only join that Tableau has to perform is between these two tables and thus avoid any duplication of data or "join explosion."
About RLS and previous versions of Tableau
Previously, Tableau was unable to support RLS workflows with extracts because of complications around row duplication and performance. Ultimately, these complications derived from the extract whose data could only be stored and queried as a single table. However, beginning in Tableau 2018.3, you can choose to store the data in your extract using multiple tables and thus enabling a workflow for RLS with extracts as you might have previously done with data sources with live connections.
For a comprehensive discussion about RLS with extracts in Tableau, read the blog maintained by a Tableau Sales Consultant who has extensive experience in this area.
Disclaimer: Clicking these links will take you away from Tableau.com. Although we make every effort to ensure links to external websites are accurate and relevant, Tableau cannot take responsibility or provide support for the external content.
Data Security(Link opens in a new window) in the Tableau Server Help
Overview of Row-Level Security Options(Link opens in a new window) in Tableau in the Tableau Server Help