[SIP-51] Dashboard Level Access

Motivation

As a dashboard provider in an organization with many subgroups inside I need the ability manage user access to dashboards and different levels of permissions(read, write, granter, owner)

use cases

1. In our org we will have hundreds of dashboards that will be based on the same dataset Therefore there is no way to manage dashboard access for specific dashboards for specific users
2. access to dashboard metadata - as a dashboard creator I have sensitive data on the dashboard metadata (iframe, plain HTML, markdown) I want to restrict access to dashboard metadata
3. current Enterprise BI solutions offer this content-type level of permissions e.g: Tableau
4. we want to make sure that /dashboard/(<Id>/<slug>) is also enforcing access. Currently, anyone can access any dashboard by just changing the URL. Sometimes there is PII on the dashboard itself like plain HTML text or an iframe so it still exposes sensitive data on the dashboard which is problematic to some of our clients
5. Airbnb and probably other orgs are fully dependent on dataset level access - they would not handle an extra dashboard level permission
6. Need to give just dashboard viewing rights and dashboard download rights to users
7. In certain Enterprises. for example financial services, it is often required to limit the accessibility of data to certain people and to have the ability to manage this centrally. This means that users only have a limited ability to publish results in dashboards to a broader public.](https://github.com/apache/incubator-superset/issues/11198)

Proposed Change

By using the RBAC principle and linking roles directly to a dashboard we can enforce an additional layer on top of the existing access mechanism that will permit access to a dashboard if the user has access to any of the Dashboard roles

100% backward compatibility to the existing dashboard security mechanism which is based on datasets

roles linked to a dashboard would provide either read or edit access

development milestones

1. enforce dashboard security using roles
2. allow token-based access to /explore_json and API/v1/chart/data to allow reading datasets only by have dashboard access for read-only purpose

Rejected Alternatives

LEVEL_ACCESS_MODE= //options ‘Dashboard’/ ‘Dataset’ this option doesn’t allow both options to co-exist and prevents Dataset access based existing solution to use the new ability none

[itsik-avidan]

👍

[ktmud]

dashboards with LEVEL_ACCESS_MODE= ‘Dashboard’ enabled will not be subject to any dataset level access.

This will be a major turn off for any organization who needs dataset level access control.

My 1) and 2) were not two options but two steps of one solution. Basically we keep current dataset level access control unchanged but add a new layer of dashboard access control.

In terms of actual implementation, you could still leverage the existing RBAC by adding an roles attribute to dashboards and a custom can_access_dashboard/can_edit_dashboard method to SecurityManager:

1. Add a new column roles to the Dashboard model, which stores FAB roles that corresponds to a business unit/user group’s dashboard view or edit role. We don’t allow specifying view access by users as it unnecessarily complicates things.
2. When publishing a dashboard, users choose which roles/user groups have access to this dashboard
3. Add dashboard_access to OBJECT_SPEC_PERMISSIONS
4. Add can_access_dashboard and can_edit_dashboard to SecurityManager which passes the right permission names and view names to can_access based on roles associated with the dashboard. E.g.

   if not dashboard.roles:
       return True
   for role in dashboard.roles:
       if self.can_access("dashboard_access", dashboard.perm_for_role(role, edit=False)):
           return True
   return False
   

5. Place these checks manually in the API, just like what we do for datasources.

In short, I don’t think an “access mode” switch is necessary, as current security model seems to already suffice in supporting the additional layer of role-based dashboard-level access control and the only extra work is adding a new roles column (like we already have in datasource.perm and datasource.schema_perm, except we add roles instead of perm to have the ability to enforce foreign key check.)

There could be a toggle to allow pulling query results from controlled datasource even if users don’t have direct access to datasource—but that has its own level of complexity and doesn’t seem to be blocking us from implementing the basic dashboard-level access control.

This is obviously a popular user demand and I’m all for addressing it, but let’s make sure the final solution is as prudent as possible.