You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by GitBox <gi...@apache.org> on 2022/04/08 23:19:08 UTC
[GitHub] [superset] bjornhauge opened a new issue, #19632: Use User model fields in RLS (row-level security)
bjornhauge opened a new issue, #19632:
URL: https://github.com/apache/superset/issues/19632
I've not yet gotten very far into superset, so forgive me if there's an important piece I'm missing.
**Is your feature request related to a problem? Please describe.**
Sometimes there is a really big pattern of generating roles and row-level security filters for purposes that do not fit the concept of static application roles very well, and instead are better thought of as dynamic identity-based attributes ("dynamic" from the application's perspective, not necessarily meaning that they'd change over time for a specific person).
For example, think about trying to make a dashboard for each employee in a company to view their own payroll deductions. Which employees exist is not a matter of "application setup" or "security model", it's a matter of user management. Unless there's a piece of Superset's RLS that I'm missing, each employee would need to have their own role, and each role would need to have its own filter. And if any of that setup failed, they'd be able to see everyone's data.
This is made especially important by the fact that Superset doesn't query data from a relational model of its own (like Power BI does, for example), meaning that each of the ultimate data source tables has to have its own RLS filters (whereas if it had its own relational models, security filters could be applied to related tables)[^1].
[^1]: This propagation of security filters would be like if a whole bunch of the queries for a given dashboard came from a single SQL statement with multiple queries, and they all referenced a single "security" CTE, and that CTE took a filter parameter.
**Describe the solution you'd like**
Add some kind of RLS filter syntax, (autocomplete? :grin:), and validation for User model attributes to the front end, and make use of them in the back end. All the other concepts such as filters attached to roles, and users assigned to roles, and so on, would be unchanged. Flask-AppBuilder makes it pretty easy to augment the User model, and I wonder if Superset could by default add a bunch of generic custom attributes.
**Describe alternatives you've considered**
In the context of the example, adding a user-specific role for each user.
**Additional context**
--
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.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] dwi13L commented on issue #19632: Use User model fields in RLS (row-level security)
Posted by "dwi13L (via GitHub)" <gi...@apache.org>.
dwi13L commented on issue #19632:
URL: https://github.com/apache/superset/issues/19632#issuecomment-1733632339
Hi @bjornhauge, I'm facing the same problem you have described. I see that the number of RLS filters and Roles would have linear to exponential growth if I go with the creation of static filter clauses for users getting onboarded in an application I'm working on. I see that the discussion is closed but I really couldn't understand the answer or how I can take this forward in a more efficient manner. I would be grateful if you could provide some insights on how you've managed to solve this.
Thanks in advance!
--
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.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] bjornhauge commented on issue #19632: Use User model fields in RLS (row-level security)
Posted by GitBox <gi...@apache.org>.
bjornhauge commented on issue #19632:
URL: https://github.com/apache/superset/issues/19632#issuecomment-1095602758
A few user attributes are already provided in functionality like this.
--
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.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] bjornhauge closed issue #19632: Use User model fields in RLS (row-level security)
Posted by GitBox <gi...@apache.org>.
bjornhauge closed issue #19632: Use User model fields in RLS (row-level security)
URL: https://github.com/apache/superset/issues/19632
--
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.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org