Tableau Server Security: Rules & Guidelines

Leading up to my Tableau Conference presentation, I wanted to put together a series of blog posts that discuss the three pillars of my discussion and approach to self-service analytics. The first pillar is Training and can be found here. Without a trained set of super users, the Security structure and Governance model you will develop doesn't matter because no one is using it. With a trained set of Tableau developers, a simple, scalable Security model is foundational to the efficient use of the technology.

In our installation of Tableau Server, we have integrations with Active Directory and SAML (Okta) setup. This allows for single sign on (SSO) and for security to be controlled by Active Directory groups, which aligns with our enterprise best practices and means that more than just the Analytics team can add/remove users from the server. With regards to the structure of our server, we have three separate servers — a production server, a staging/QA server, and a test server. They should be practically identical in terms of structure.

The structure developed organically over time and is divided into sites representing different departments. Within each site are projects that are for teams within departments or actual projects being worked on across the entire department. This organizational structure has worked for us but may not work for everyone. I encourage you to let the users direct the organizational structure of the server while also providing guidance in thinking about future growth and changes. We currently do not use nested projects, though a user recently inquired about them. These nested projects further divide and organize workbooks and datasources.

It is at the highest project level that we assign permissions, requiring that the project is locked. We assign permissions to a group, not an individual. The benefit of using groups is that access is managed via Active Directory. This means that Tableau Server admins don’t have to manually manage user access and (hopefully) there is a much larger group of IT professionals that can help manage the Active Directory groups.

When deciding the capabilities to give users, I wanted to start with something simple. Back when I first designed this model I was a new server admin and the previous flow chart of permission evaluation was difficult to understand. Instead, I reviewed the capabilities listed here and decided to specifically choose whether to choose or deny the capability. This seemed to be the clearest path forward.

Over time I have developed a list of rules (that are unbreakable) and guidelines (defaults, that can be modified). They are listed below and available as a pdf using the link at the bottom. I go into much more depth during my conference presentation, so hopefully you can attend!