[SIP-55] Extending the security framework to provide data level security

[SIP] Proposal for Extending the security framework to provide data level security

Motivation

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.

Typically this is managed on the data/resource level. For example user “bolke” has access to transaction data from Asia but cannot access transaction from Europe. It might be that “bolke” has access to aggregated data, like a dashboard or a chart, but not to the original datasource.

In such a context you would like to be able to set permissions in a leveled way like:

1. Dashboard
2. Chart -> (Table / View, Function, Column(s))

This type of resource based access is equal to for example what is implemented in Presto.

Superset currently does not have such a model. It only implements table/schema/database with row level filtering it does not have a fine grained permission model on dashboards and charts. This limits the usability in a enterprise context. It also has a technical limitation as we cannot enable the cache as that ignores the permission model that works on the database level (e.g. Presto, Druid etc).

Proposed Change

A new decorator @has_access_resource that takes the action (read/export etc), the resource type, resource name, and its specification (e.g. Chart -> type, table/view, metric, column(s). The request itself (GET/POST) should also be available to this decorator as permissions might be dependent on time of the day, geolocation etc.

Permission checks can be expensive (we have over 1500 policies). Therefore I suggest a default “pass” implementation also for backwards compatibility. The check itself can then be ‘outsourced’ to highly optimized systems like Open Policy Agent or Apache Ranger.

New or Changed Public Interfaces

Optionally a Securitymanager that implements has_access_resource can be provided in the configuration

New dependencies

None

Migration Plan and Compatibility

None, this is backwards compatible.

Rejected Alternatives

It was mentioned that column access could be solved by proxy with views that expose subsets of columns. This creates an extra burden either in maintaining the Dashboard (which is the not possible to centrally manage) or with the Database team , while the global cache can still not be enabled.

cc @mistercrunch

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label #enhancement to this issue, with a confidence of 0.92. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[rusackas]

Since this issue is closed and inactive, we’ll also consider the SIP/proposal process closed as well. If you want to rekindle this proposal, please re-open this Issue, and send a new [DISCUSS] thread to the dev@ mailing list. Thank you!