Row Level Security is a concept many Tableau users may have avoided learning more about or even worse - run into roadblocks implementing it after a less than helpful google search. It's admittedly a confusing topic, complicated by the fact that there are actually a few different methods you can use to implementing it in your work. After seeing many in the healthcare space ask about it, Jana Klinger and I partnered up to give a presentation on this topic at the February 2020 Virtual Healthcare Tableau User Group. The video recording of our talk is available here and content will be posted on the user group page here but thought a blog post detailing this topic may be helpful for those who prefer a write up. Screenshots were taken from our presentation.
So what is row level security anyway?
Tableau's Help Guide in 2020 provides this description of row level security, "When you share workbooks with others by publishing them to Tableau Server or Tableau Online, by default, all users who have access to the workbooks can see all of the data shown in the views. You can override this behavior 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."
In short, it's how you can make sure those accessing your work on Tableau Server are only able to see the data they're supposed to - without having to make separate workbooks and filters for everyone in your organization.
Why should you care/know about it?
This is a concept that is relevant to Tableau clients who share their work on a Tableau Server and are looking to scale their reporting while still being thoughtful of data privacy and security.
This is something that has use across all industries but is especially relevant in healthcare due to considerations of patient privacy, clinical research, collaboration with other institutions, and roles involved in the care of every patient. Reports that include patient medical info or individual clinician reporting are great use cases where row level security may be useful.
Available methods for row level security
As mentioned at the top, there are actually several methods to implementing.
Manually Defined User Filters
Underlying Data Structure
Impersonation
Manually Defined User Filters
You manually control who sees what.
Pros
Quickest and easiest approach
No additional data sources or systems required beyond those used to create the workbook
Report developer has most control over who sees what
Cons
Difficult to scale
Report developer has most control over who sees what (yes, this is a pro and con)
Steps
1. Build a workbook
2. Sign into Tableau Server from your Tableau Desktop
3. Click Server - Create User Filter
4. Choose the field you want to use to filter on
5. Name the filter (optional but best practice)
6. Select a user or group
7. Choose the specific field values you want them to see
8. Repeat 6 & 7 for other users and groups
9. Hit OK
10. Drag the new User Filter to the Filters Shelf, checking functionality with the Filter as User (bottom right of workspace)
Click to see the live demo from our talk!
Underlying Data Structure
Let your data source control who sees what.
Pros
Higher level of scalability than Manually Defined User Filter approach
New dimension fields can be integrated through this approach at a data source level without needing to republish or change existing workbook
Cons
Report Developer needs to have permissions to active directory or Tableau Server users
Steps
1. Build a workbook
2. Add a Data Source that maps user credentials and permissions
3. Create a Username Calculation
4. Blend the data sources together using the new Username Calculation
5. Use a Data Source Filter to exclude all but the current user
6. Create calculation(s) to replace any sensitive data
7. Use the new calculation in place of the original sensitive data
8. Finally, disable the tooltip or hide the field in your dataset
Click to see the live demo - great job Jana!
Impersonation
Let your database administrator and access management team control who sees what.
Pros
Pushes management of who can truly see data at your database administrator or access management team's - taking the burden off of you, the report developer
Cons
Only works for live data source connections (no extracts)
Requires alignment of largest number of staff and systems - often owned by different teams to execute effectively
Only applicable to SQL Server data sources
Steps
1. A database admin grants your Tableau Server Run As account IMPERSONATE permissions to your SQL Server database
2. Ensure you (the report developer) have read access to your required SQL Server database table so you can actually connect to build your dashboard.
3. Ensure that all your workbook viewers have credentials to your SQL Server database that match the credentials they use to log into Tableau Server
4. Use Windows Integrated Security for live connection to your SQL Server (the preferred option)
5. Develop your workbook and when publishing set the authentication to "Impersonate via server Run As account"
This method does not currently have a live demo just the above screenshots.
Summary
As you can see, there are different approaches to implementing row level security in your reports with each having it's own pros and cons. The manually defined user filter approach puts the most control into the report developers hands but struggles to scale. The data source filter method addresses the scale issue but requires the report developer to have access to user credentials. The third method addresses the cons of the first two methods but often requires alignment of various teams at an organization (plus it cannot be used for extracts).
I hope this has helped clear up this potentially tricky topic but feel free to reach out with any additional questions!
Comments