Multi-tenancy

Tableau Server has built in multi-tenancy using the Sites feature. Best practice in a multi-tenant deployment is to give each tenant their own site. For an explanation of how multi-tenancy in Tableau maps to multi-tenancy in your database systems, read The Tenets of Tableau Templates on Multitenants.

Authentication

Everyone who can see content on the Tableau Server needs to be a user on at least one Site in the Tableau Server (this includes the default Site).

Syncing Users to the Tableau Server

When you first set up Tableau Server, it can be in one of two modes (for the whole server)

• Local Authentication
• Active Directory
• LDAP

When linked to Active Directory, every user must be on a linked AD domain. AD Groups can be added to the Tableau Server, and then set to sync on a schedule.

Local Authentication means that all of the users exist independently in the Tableau Server. You can sync them into the Tableau Server using the REST API. An example of using the REST API to sync users is here. If you have some users in AD and others that are not, use Local Authentication, then sync the AD users in via a script that uses the REST API.

Single Sign-On (SSO) Methods

Tableau supports many different methods for single sign-on (SSO). All of the details for getting them set up are covered well in the Administrators Guide

The following Venn diagram (visual best practice!) is my own, showing which methods are commonly seen with the different ways of syncing users

If you are using an SSO method, you may be concerned with making sure that the Tableau session from your chosen method stays in sync with that of your application. This is covered in the Embedding Page

If you are not embedding Tableau content into another web page, but still want to implement SSO, you can use SAML or Trusted Authentication (make sure to turn on Unrestricted Trusted Tickets ).

If you need to keep too many people from logging in at once, you could implement some concurrency checks prior to going through with SSO. This post also shows how to force a session logout through the REST API.

Trusted Authentication Best Practices

Trusted Authentication / Trusted Tickets is the most common SSO method for embedding Tableau Server into another application. It works by defining:

• A limited set of server machines
• with Static IP addresses
• that can be trusted to not be impersonated (therefore, in the same private network as the Tableau Server machine)

The basic implementation of Trusted Authentication is covered in the official Tableau documentation under How Trusted Authentication Works, while the Expanded Trusted Tickets diagram dives into how it works in a secured Internet-facing environment.

However, the best practices for complex embedding involve the following:

• Session-level Single-Sign On , where a single Trusted Ticket redemption initiates the session
• A Ticket Broker machine, which is a single static IP machine that the Tableau Server trusts to requests Trusted Tickets, that other machines with dynamic IPs can ask to retrieve a trusted ticket for them. A mechanism of trust between the Ticket Broker and the other web application machines must be established as well.
• Killing a Tableau Server Session , if in an incredibly secure environment
• Possibly using Unrestricted Trusted Tickets to enable additional features (alerts, subscriptions, custom views)

Authorization / Permissions

Authorization, i.e. what content people can access and with what features, is handled via Groups and Permissions in Tableau Server. Users can belong to multiple Groups. Projects, workbooks, and data sources can all have Permissions assigned at the Group or User level.

Best practice is to lock permissions to a Project and then assign the permissions at the Group level. This allows you to control access by adding or removing users from the appropriate Groups.

Data Security, what actual data a user sees when accessing a Workbook or Data Source that they have permissions to see, is handled separately in Tableau as Row Level Security.