Row Level Security in the Data Source
If your organization has already put effort into building out Row Level Security (RLS) in a data source, you may be able to use one of the following techniques to take advantage of your existing RLS. In order to leverage the data source’s security models, live connections are required. Additionally, these techniques are likely not available in Tableau Online; the Tableau username for Online is a unique email address which is not typically the user identity on the data source side.
It is not necessarily easier or better to implement a built-in RLS model vs. building it with Tableau in mind; these techniques are generally leveraged when an organization has already invested in these technologies and they want to take advantage of the investment.
Impersonation (Microsoft SQL Server)
Microsoft SQL Server (and a few related systems) can be configured so that users of the database only have access to views with RLS filters built in, either utilizing Security Junction Tables or views built by the DBA. Tableau can take advantage of this using a concept called “impersonation.”
When publishing a Tableau Data Source containing an MS SQL Server connection to Tableau Server, there are two authentication options available to take advantage of impersonation. The menu you see will depend on whether you logged into the SQL Server using network authentication or by entering username/password credentials.
To enable RLS filtering for any user who can access the Published Data Source in Tableau Server, either the AD Run-As Account or the embedded SQL server credentials must have permission to EXECUTE AS for all of the Tableau users in the database that will be accessing the dashboard or data source. All Tableau users must exist in the database server as users, with SELECT rights for the Views you are trying to connect to (and have RLS applied to). See Impersonation Requirements for the comprehensive list of requirements.
Kerberos & constrained delegation
Constrained delegation within Tableau Server using Kerberos operates similarly to impersonation in that it allows Tableau Server to use the Kerberos credentials of the view of a workbook or view to execute a query on behalf of the viewer, so if RLS is set up on the data source, the viewer of the workbook will only see their data.
To see the comprehensive list of data sources where Kerberos delegation is supported, see Enable Kerberos Delegation. Active Directory is required; the computer where Tableau Server is installed must be joined to the Active Directory domain. The authentication method(Link opens in a new window) specified when publishing the data source must be viewer credentials.
Note that Kerberos can be leveraged for RLS when using Microsoft Analysis Services.
OLAP Cube connections in Tableau do not have the equivalent of a data source filter, which is required for the entitlements table-based RLS method in Tableau, or access to the USERNAME() function. For these reasons, Kerberos and constrained delegation is a recommended approach to RLS with OLAP data sources, which allows Tableau to leverage user filtering that has already been implemented on the OLAP Server side.
If the users viewing the dashboard will not be part of the domain, then the manual approach to creating user filters is possible. However, because the User Filter Set generated cannot be added as a data source filter, and will instead exist on the filters shelf, it is important that Web Editing and Download Workbook functionality is not permissible for any published views utilizing this method.
SAML delegation & SAP HANA
If Tableau Server is configured to use Configure SAP HANA SSO to provide a single sign-on experience, the viewer credentials are used to execute the query as that user, which will operate within whatever security is applied on the user level. The authentication method(Link opens in a new window) specified when publishing the data source must be viewer credentials.
Initial SQL to force a user-specific session (Oracle VPD)
Initial SQL allows you to specify a SQL command that is run when the connection is made to the database for the purpose of setting up temporary tables to use during the session or to set up a custom data environment.
For Oracle VPD, you can set up a session specific to a user by running a particular stored procedure or function to set the context of the database connection to match the Tableau user’s username:
begin DBMS_SESSION.SET_IDENTIFIER([TableauServerUser]); end;
The same high-level requirements hold true for using this for RLS as with impersonation; the DBA must set up VPD and all of the associated users to exist on the database.
On MS SQL Server, you could force an EXECUTE as command (however, this is similar to what Tableau does with impersonation already) :
EXECUTE AS USER = [TableauServerUser] WITH NO REVERT;
Note: If the data source is embedded and a user has permissions to web edit or download the workbook, then the RLS is nonexistent since the initial SQL enforcing it can be easily removed. The data source should be published separately as opposed to being left embedded in the workbook.
Comparison matrix for Row Level Security Methods
|Entitlements table (Recommended)||
|CONTAINS() with extracts||