RowLevel Security Generation using Api

[Synarcs]

We have recently implemented Superset Security using OAUTH and custom roles. However, these custom roles are from different clients where we filter data for each client using a row level security based on his/her ssn id. So essentially we provide a row level security for all the roles with all the set of tables containing ssn id and the where clause value in rls is dynamically populated using jinja functions.

However, due to increasing complexity of our use case we want a cascading rls for the same role and filtering values with different Jinja functions. Hence, we tried to generate rls using api rather to do it all via UI.

I tried to generate rls on fly that is controlled by our security manager, I tried with 2 endpoints for generations

1. /rowlevelsecurityfiltersmodelview/add (sending a form data payload) [Note there is no CORS or unauthorized issue we are able to send request but the response is not a valid payload ] The Error message is [Not a Valid Choice] with some html markup in response.

2. /rowlevelsecurityfiltersmodelview/api/create (sending application/json payload the response this time is as follows)

How to reproduce the bug

Generation via the rls api

1. Go to ${superset_host}/rowlevelsecurityfiltersmodelview/api/create with the json payload similar to the row level security form payload rowLevelPayload = { clause: 'ssn_id= {{ current_role_JinjaFilter() }}', filter_type: "Regular", tables: [all the set of tables to be added], group_key: null roles:: [all the role id the filter to be applied] } Generation via the rls form post request Go to ${superset_host}/rowlevelsecurityfiltersmodelview/add with the form data payload similar to the row level security add form payload
2. See error message as mentioned in the image above

Expected results

I expected a rls security can be added via api in the same way it is done using UI

Actual results

Error Message (Validation Error message) in response.

Screenshots

Attached ScreenShots above of the Error

Environment

(please complete the following information):

• latest version of chrome

• superset version: latest version

• python version: 3.8.2

• node.js version: 14

• any feature flags active: ROW_LEVEL_SECURITY=True

• [ Y] I have checked the superset logs for python stacktraces and included it here as text if there are any.

• [Y ] I have reproduced the issue with at least the latest released version of superset.

• [ Y] I have checked the issue tracker for the same issue and I haven't found one similar.

[Synarcs]

Any Help would be helpful, needed it urgently due to strict project timelines. Thanks in advance.

[srinify]

Thanks for opening this issue Vedang. Participation in Github issues is opt-in and Superset is an open source project not owned by any company, so just a heads up that it might be a while before this bug is validated / replicated and fixed!

[rusackas]

@vedangparasnis while I realize this was urgent, I realize it's gone a bit cold. I'm wondering if you're able to validate whether this is still an issue at all, or whether it's important to you. If not, it might be time to call it cold/stale and close it out. Thanks either way!!!

[amartincolville]

hello! did you ever manage to use/enable the endpoints @vedangparasnis ? Automating this would be of great great as I am attempting something very similar. @rusackas could this be left open as I believe it is still an issue, even with stable versions of Superset (I am using 2.0.0).

[rusackas]

Curious if 2.0.1 or the 2.1.0 release candidate solve this. Leaving open for now.

[Synarcs]

In our case we have custom security manager with custom roles and achieving most of it using Jinja, since we have data warehouse on mainframe db2, and solve most of our multitenancy problems using database mutation on superset. So right now we have a single role to suffice our need. We are now on 1.5.0 version. But I think adding or extending the row level security api, would be quite beneficial to handle more complex multi tenancy implementations. Having a mixture of database, query mutation and row level security.

[amartincolville]

great to know @vedangparasnis ! We are currently exploring the DB_CONNECTION_MUTATOR flag to enable this or even cusotm jinja macros. Also also have a custom security manager in place that integrates with okta and gives out the appropriate roles to users. We would also have to impersonate Reports with the ALERT_REPORTS_EXECUTE_AS flag or similar, which would apply RLS on all levels. Do you have any further information or code you can support with? Would be much appreciated!

[phbernard]

I'm looking for this feature too.

We want to use Superset as the BI companion of a SaaS product. It would make sense to programmatically create the appropriate Row Level Security filters as new SaaS accounts are created.

[pyryjook]

I'm also interested in this feature.

Sorry for side stepping the conversation slightly from the API bug itself, but I imagine the automation for this could be something one could do with the CLI? Something like: superset rls set (or why not the full words instead of the abbreviation, depending). What do you think?

Is this something that a Superset noobie contributor like me could try to implement? If so, any pointers towards the section in the source code where the implementation might belong to and where there would be some context for it?

Or is this merely something that needs significantly more familiarity with the project or/and the source code?

[rusackas]

Hi there, and sorry this has gone quiet for so long - it's been about six months since the last comment. We're no longer supporting Superset 2.x or prior, and since it's been a while since this thread saw any activity, I'll close this as stale. If this is still an issue in Superset 3.x or newer, we can re-open this, or feel free to open a new issue with updated context, which might be good since the thread is a bit wandering, and we might need a reset with a reproducible test case (custom code and security managers are difficult to support). Thanks, and again, happy to re-open if anyone feels strongly that this original issue needs to be kept open.