Tableau Server on Windows Help

If your organization has already put effort into building out row-level security (RLS) in a database, you might be able to use one of the following techniques to take advantage of your existing RLS. In order to leverage the database’s security models, live connections are required. Additionally, these techniques are likely not available in Tableau Cloud; the Tableau username for Tableau Cloud is a unique email address that is not typically the user identity on the database 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.

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.

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 using 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 and 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 database, the viewer of the workbook will see only their data.

To see the comprehensive list of databases 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 Cubes

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 databases, 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 using this method.

SAML delegation and 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 enables 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 instead of being embedded in the workbook.

Comparison matrix for row-level security methods