june 01, 2023
Creating users with limited privileges in Apache Superset.
Developing analytical systems with regard to end users implies the absence of unnecessary information unrelated to the final product. In Apache Superset, this is achieved through the creation of role-based models. The platform comes with a standard set of roles:
— Admin: administrators who have all possible privileges, including granting or revoking rights of other users and modifying other users’ dashboards and panels.
— Alpha: users who have access to all data sources, can add and modify them, but cannot grant or revoke access to other users. They are restricted from modifying objects they do not own.
— Gamma: users who can consume data from data sources to which they have access through an additional role. They only have access to view slices and dashboards created from the data sources they have access to.
— SQL Lab role: provides access to SQL Lab.
These listed roles are suitable from a development perspective; however, none of them are suitable for the end user. We have identified two approaches to address data access issues depending on the task at hand:
1. Creating a role with limited privileges that includes:
- Access to published dashboards.
- Access to final data, but not to the data sources.
- Access to view links and send them via email.
- Hiding development tools and query viewing areas.
1.2 In the upper right corner, above the table, click on the «+» sign to create a new role.
A menu will open where you need to enter the role name and select the necessary permissions for it from the dropdown list.
The following is a list of permissions sufficient for user access to published dashboards in our SuperSet version (v2.0):
- can read on Chart,
- can read on Dashboard,
- can fave dashboards on Superset,
- can fave dashboards by username on Superset,
- can favstar on Superset,
- can dashboard on Superset,
- can profile on Superset,
- can recent activity on Superset,
- menu access on Dashboards,
- all datasource access on all_datasource_access,
- can get on Datasource
If it is necessary to provide access to links and passing filter parameters:
- can write on DashboardFilterStateRestApi,
- can read on DashboardFilterStateRestApi,
- can write on DashboardPermalinkRestApi,
- can read on DashboardPermalinkRestApi,
- can write on ExplorePermalinkRestApi,
- can read on ExplorePermalinkRestApi,
- can share dashboard on Superset,
- can share chart on Superset,
- can explore json on Superset
Click on the «Save» button in the lower left corner.
1.4 Moving on to user creation. In the upper right corner, similar to roles, click on «Settings» => «List Users». This will open the list of users. Click on the «+» sign to create a new user. In the pop-up window, fill in the following fields:
— First Name
— Last Name
— User Name
— Is Active? (check the box)
— Role (select the desired role from the dropdown list)
— Set password and confirm it.
Click on the «Save» button. You can log in with the new user to verify the result.
2. Restricting data access at the dataset level requires ensuring the functionality of Jinja templates.
2.1 To demonstrate the solution, let’s create a test dataset and table:
select ‘user1’ as user_name, 1 as val
union all select ‘user2’ as user_name, 1 as val
2.2 Go to «Settings» => «Row Level Security». Click on «+» to create a new filter. In the pop-up window, enter the filter name, select the table to be filtered, and choose the role. In the last window, enter the condition, which in our case will be:
user_name = ‘{{ current_username() }}’
where user_name is the field for filtering, and {{ current_username() }} is the query for the username using Jinja templates.
Click on the «Save» button. Log in as the user «user1» to verify the result. The test table should now only display one row.
If you examine the query, you will see that at the end of the table, there is a condition automatically added.
2.3 If you need to provide pre-filtering of data, you can add the condition at the dataset level. Let’s modify the test query to demonstrate this solution
Save the dataset and log in as the user «user1» to verify the solution. The table should now be filtered by the username, similar to step 2.1.
However, the query will look as follows:
