logo

Access control with Atoti+

Hui Fang Yeo

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: 

ROLE_USER

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.

ROLE_ADMIN 

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.

ROLE_SHARE 

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 = session.security.basic.create_user("John", password="X Æ A-12")
session.security.individual_roles[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 = session.security.create_role(
    "ATOTI_ROLE_INSPIRE",
    restrictions={("parent_co", "parent_company"): ["Inspire Brands"]},
)

role_restaurant = session.security.create_role(
    "ATOTI_ROLE_RESTAURANT",
    restrictions={
        ("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 = session.security.create_role(
    "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.

Like this post ? Please share

Latest Articles

View All

Atoti Limits 4.0: An improved user experience

Read More

Atoti Limits 4.0: Simplified project structure and upgrades

Read More

NEWSLETTER

Join our Community for the latest insights and information about Atoti