Tableau offers Business Intelligence (BI) software that is great for generating meaningful graphs and visualizations of data. The software can query many different sources for data and aggregate these into illustrations that tell the story behind the data.

When using BI tools, there is almost always a need to control what users have access to. This spans from controlling what a user can do within an application, what information that can be accessed through an API or down to the data layer with controlling exactly what data a user can see.

A powerful way to achieve this balance is by using Attribute Based Access Control (ABAC) to define centralized access control policies that in turn can apply fine-grained authorizations for different scenarios. Several of these approaches have been outlined in previous blog posts.

In this blog, we are going to take a look at how fine-grained authorization can be applied to Tableau, to the data that is retrieved from an underlying data source within an enterprise.

Tableau’s data query capabilities work across different data sources, so the tool can retrieve the relevant data to the framework the user is setting up; and the right access control measures must be in place to ensure sensitive data is protected, but that the right data is available for analysis. There might be very specific access control rules that need to be implemented based on specific attributes of the data or specific attributes of the user. Some common examples include:

  • A user can only access information for their own country/region/state or similar
  • A user can only access data for their own department
  • A user can only see a value for a record that belongs to their own department

Although it is possible to define the actual query in such a way that the retrieved data is performing some filtration of exactly what is being fetched, that approach is not centralized and not very scalable. More importantly that approach hopes the person writing the query doesn’t attempt to see sensitive data they shouldn’t have access to which is not how data security should be applied. Levering an externalized ABAC authorization engine enables control of the data being accessed and creates a very robust and flexible environment that allows for dynamic changes to policies.

Let’s look at how Axiomatics SmartGuard for Big Data can be used to centrally enforce what data someone using Tableau can access.

The SmartGuard Architecture

Protecting and securing data accessed by applications such as Tableau can be challenging.  Axiomatics’ SmartGuard rises to the challenge by using a centralized ABAC system to secure data across a variety of data stores. The data store can be any number of different systems and the SmartGuard solution handles Hadoop, and more specifically, the SQL layers that are used to access the data in Hadoop. This could, for example, be HAWQ, Hive, or impala – to name a few. (As a side note, Axiomatics also provides solutions to cover other data stores such as relational databases through the Axiomatics Data Access Filter (ADAF) solution.)

SmartGuard accomplishes this by intercepting the call to the data store and applying a filter before data is fetched. This ensures sensitive data only leaves the data store to those that are authorized to view it under the right conditions. In order to do so, SmartGuard:

1) Uses an Interceptor Agent to hook into the flow and first make a callout to the SQL Transformer before the call to the data store happens. The Interceptor Agent is a JDBC or ODBC driver that is executed before the original JDBC/ODBC.

2) The original query gets analysed by the SQL Transformer which then passes on to the SQL Filter Service (SFS).

3) SFS applies the ABAC policy to the original SQL query and if needed SFS will retrieve additional attributes from underlying Attributes sources such as LDAP/AD, databases, or any other data source. This could be information about the user’s role, group membership, cost center, or other attributes that describe the resources further, such as the owner or location of an account.

4) Based on the ABAC policy and the attributes, the SFS will construct a set of filter statements that are returned to the SQL transformer and there are appended to the original SQL query. This is also where data masking can be applied to the data based on configuration. The policy can include parts where a decision is made to mask data, and the SQL Transformer can apply a specific filter mask to, for example, a credit card number, social security number, or any other type of data.

5) The modified SQL query is then returned back to the Interceptor Agent.

6) The modified query is sent on to to the data store.

7) The data store then executes the modified query and masked / filtered data is returned back to the application, again in our case Tableau.


Regardless of the method used to access data, it is important to ensure that only authorized data is accessible. Leveraging an ABAC solution such as Axiomatics SmartGuard to intercept and centrally apply policy-based authorization, filtration, and masking of data allows for a powerful and flexible way to take control of accessible data.

Attributes and policies can change, leading to different results in data that is returned to Tableau from the data source. However, the configuration in Tableau that defines how data is retrieved can stay exactly the same. This is the result of externalizing the authorization logic for the data from Tableau, and more specifically, from the query that is used to fetch the data.

For more information on how SmartGuard can help your organization with a new or existing deployment, check out these additional resources:

  1. [Webinar] Authorization for Big Data: Introducing SmartGuard
  2. [Blog]  Dynamic Authorization for Multiple Databases – How it Works
  3. [Blog] How to Write Authorization Policies for Big Data

Leave a Reply

Your email address will not be published. Required fields are marked *