Access control with Atoti+

Restrict viewing rights up to data level

In this article, we explore the topic of access control for the atoti web application as part of a series explaining how we can implement secured and managed access in atoti v0.7.0 through the Atoti+ plugin.

Check out our other pieces from the series:

Check out the corresponding video:

Access control around users and their roles

Access control plays an important role in BI web applications. In atoti, we can apply access control to:

  • Accessing objects such as dashboards, folders and widgets
  • The Share function on dashboards and folders
  • Which data is viewable   

We can implement access control by:

  • Individual users
  • Roles

System predefined roles

As depicted in the diagram above, all users (including administrators) must have the role ROLE_USER to access the atoti web application.

ROLE_USER is a system pre-defined role in atoti, and so are ROLE_ADMIN and ROLE_SHARE. They have the following access: 


We must grant all users accessing the application this role. They are able to access all data by default unless limited by the access definition of another role. 

Users can only access objects such as dashboards, folders and widgets that are either:

  1. created by themselves
  2. granted access to them by the creator or users with Editor permission to it.

Users do not have access to the Share function by default.


As the role name suggests, we grant this role to administrators. Users with this role are able to access all data and all objects in the web application by default.

Administrators do not have access to the Share function by default.


Users with this role are able to access the Share function. They can share objects such as dashboards, folders, widgets and filters.


With ROLE_SHARE, users are able to see the Share function that allows them to grant other users the Editor or Reader permissions to the object.


When we grant users the Editor permissions to an object, they are able to make updates to or delete it. When we grant the Reader permissions to users, they cannot save changes to the original object. Instead, they can save the updated object as a new object. 

User-defined roles

Depending on the authentication mechanism used, we can define roles either in atoti or the authentication provider according to the needs of the organization. The following code snippet shows how we can create a user and assign the role “ROLE_USA” in atoti while using basic authentication.

session = tt.Session(authentication=tt.BasicAuthenticationConfig())
elon ="John", password="X Æ A-12")[elon.username].add("ROLE_USA")

In this example, we simply added another “label” to the user’s list of roles. These roles purely serve as categorization, e.g. granting specific folders or dashboards to a given role via the Share function. The users have access to all of the data available in the cube.


Roles with restricted permissions

Users sometimes create dashboards to be used as templates for roles within different business domains. They will then duplicate the dashboard with a different set of filters according to the roles it is granted to. E.g. In the below dashboard granted to TEAM C, 3 parent companies under the charge of TEAM C are set in the filter below.



This works for cases where the confidentiality of data is not important across teams. Users have the ability to change the filter and access parent companies under the charge of other teams. Beyond the lack of confidentiality, we also ended up creating many similar dashboards.

A better way is to restrict the data each role has access to. This way, we pre-set the range of data each user can see on the same dashboard depending on their roles.

role_inspire =
    restrictions={("parent_co", "parent_company"): ["Inspire Brands"]},

role_restaurant =
        ("parent_co", "parent_company"): ["Restaurant Brands International Inc."]

In the above example, “parent_company” is a column in the dataset, translated into a hierarchy in the cube. When we assign the role “ATOTI_ROLE_INSPIRE” to users, we limit their data access to only those related to the parent_company “Inspire Brands”. Likewise, we can limit users’ access to data related to the parent_company “Restaurant Brands International Inc.” by assigning the role “ATOTI_ROLE_RESTAURANT” instead.


Two users with different roles, see different data when accessing the same dashboard.


This way, we only maintain a single dashboard across teams and at the same time, ensure confidentiality of data regardless of the filter that is applied.

Impact of Roles stacking on data access

We can assign multiple roles to a user, thereby affecting the range of data the user can access. When we stack roles with restrictions on the same hierarchy, users can access a larger set of data. However, when we stack roles with restrictions on different hierarchies, then we get a more restrictive view.

To better understand this, we create another restricted role called “ATOTI_ROLE_BURGER” where we limit the data access by the category “burger”.

role_team_burger =
    "ATOTI_ROLE_BURGER", restrictions={"category": ["burger"]}


Crossing restrictions on different hierarchies will result in more restricted data access.


A user with only ROLE_USER assigned has access to all the data in the cube.

Let’s examine a user who is granted a restricted role such as ATOTI_ROLE_INSPIRE on top of ROLE_USER. This restricts the user’s access to the data listed within its restriction, i.e. those that fall under parent_company “Inspire Brands”.

Now, suppose we assigned the roles ROLE_USER, ATOTI_ROLE_INSPIRE and ATOTI_ROLE_BURGER to a user. He/she can, therefore, only access data related to parent_company “Inspire Brands” of category “burger”.

Let’s assume the dataset is made up of only two parent companies “Inspire Brands” and “Restaurant Brands International Inc”. In this case, a user assigned the roles ROLE_USER, ATOTI_ROLE_INSPIRE and ATOTI_ROLE_RESTAURANT, is the same as one who only has the role ROLE_USER

However, in reality, the dataset has more parent companies than the two mentioned above. Hence, ATOTI_ROLE_INSPIRE and ATOTI_ROLE_RESTAURANT will result in access to only a subset of data.

In conclusion

There are many benefits of implementing access control in the atoti web application. For one, with proper access control to data, we can streamline the use of dashboards across teams. At the same time, we ensure data confidentiality. 

In addition, with Reader permissions, we can share dashboards without worrying about other users tampering with or changing the dashboards. Not to forget, each user has the ability to create their own private resources and share them when necessary.

Find out more about security with Atoti+ in our sample use case in our atoti notebook gallery.

Latest posts

Understanding Logs in Atoti
From the default log to how to configure additional logging Application logs are extremely important in any system! Most commonly, they are used to troubleshoot any issue that users may encounter while using an application. For instance, developers use them for debugging and the production support crew uses them to investigate outages. Not just that, in production, they are used to monitor an application’s performance and health. For instance, monitoring tools can pick up certain keywords to identify events such as “server down” or “system out of memory”. It can also serve as an audit trail to track user activity...
Atoti: Working with dates in Python
What is the most problematic data type you have ever dealt with when working with data? I would say dates! Depending on the locale, dates come in different formats such as YYYY-mm-dd, d/m/YYYY, d-mmm-yy etc. Not to mention, sometimes it comes with timestamps and time zones! We can let programs infer the date format or explicitly cast the data to date with a specific format e.g. in Python with Pandas DataFrame: What if we open the CSV file in Microsoft Excel, update it, and try to read it again? The above code snippet will throw out exceptions such as this:...
Understanding conditional statements in Atoti
When do we use filter, where and switch statements? We know that we can perform aggregations and multi-dimensional analysis with Atoti. Aggregation is not always as simple as 1 + 2. Sometimes we end up in an “if…else” situation, and that is where conditional statements come in. Let’s explore some examples with the XVA use case from the Atoti CE Notebook Gallery. Some definitions before moving on: Measures – we refer to metrics or quantifiable data that measure certain aspects of our goals. In the code snippets below, they are represented by measure[<name of metrics>]. Members of a level –...

Join our Community

    Like this post ? Please share

    Follow Us

    atoti Free Community Edition is developed and brought to you by ActiveViam. Learn more about ActiveViam at