bolkedebruin opened a new issue #14806: URL: https://github.com/apache/superset/issues/14806
## [SIP] Proposal for Improving the security stucture and move to resource based model ### Motivation I have been trying to implement centralized security for Superset. This means externalizing any security checks to a different service that resides outside Superset. For example, if a user needs access to a view or a data source this check would be done by and external service like Apache Ranger or Open Policy Agent. This is major thing when deploying Superset in an enterprise context where one would like to manage access rights on a platform level rather than a component level. This has proven difficult as the security implementation is not well structured at the moment. This means that segregation of duties is hard or impossible to implement. The challenge is that Superset as a convoluted security model. To illustrate here are several examples. * The "Admin" role is a special role that gets special permissions verified by the application layer rather than the security layer. For example `DashboardAccessFilter` asks the security layer if the `is_user_admin` rather than asking the security layer if the user has view access to a particular resource. * `get_datasources_accessible_by_user` is unable to distinguish whether a user has `use`, `view`, `edit`, `write` access to the different datasources. Resulting in an all or nothing approach. * `ChartFilter` first checks if the user has `can_access_all_datasources` (resource: datasource) and if so allows access, but if the user hasn't it checks if the users has access to `user_view_menu_names` on `datasource` (with ambiguous `datasource_access`) or to `user_view_menu_names` on `schema` (again with ambiguous `schema_access`). Note these are different kinds of resources (datasource, schema). ### Proposed Change My proposal is to 1. Restructure the security models so that every check will be done by the security layer. `is_user_admin` and alikes should never be called from the application layer. 2. Access to resources should be checked with `hasPermission(user, action, resource)` of course including metadata like Roles, originating IP, proxy addresses etc. `Resource` has ownership as metadata. 3. Actions can be (this list is probably not complete) `view (like in view dashboard), read (like in read query), execute (like in execute query), write (like in change dashboard, edit query, delete query), embed (like in include this chart in this HTML page). ### New or Changed Public Interfaces Security Manager plugins would need to be updated to follow the new resource based permission model. ### New dependencies - None ### Migration Plan and Compatibility Open to suggestions if required. ### Rejected Alternatives For discussion. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
