[SIP] API Row Level Security: get rls by username or roles via API (tested on Apache Superset 2.1.0)

[frlm]

SUMMARY

I have created the following SIP to give the client-side possibility to generate an embedding request by retrieving the row level securities defined on the UI page:

Providing either the username of the user or the role already defined on Apache Superset, API returns the list of RLS to be provided to body of endpoint /api/v1/security/guest_token/:

Otherwise, the client making the request must know in advance the settings provided at the user interface level. The following endpoints generate output considering the filter type (Basic / Regular) and the presence or absence of the Group Key. Right now a user without providing an rls but only the default value [ ], can display all the data within the dashboard, in my case I needed to manage the display of the type of data with respect to the user requesting the embedding. The output of request will be list of dictionaries with "clause" and "dataset" as keys, e.g:

[{"clause":"(province = 'AG')","dataset":25},{"clause":"(gender = 'boy')","dataset":2}]

If the different rls filters associated with the requested user or role have the same group key, the filters associated with the same dataset will be merged using the OR condition, e.g:

[{"clause":"(province = 'AG') OR (province = 'SI')","dataset":25}]

Proposed Change

I created new two endpoints:

• /api/v1/security/get_rls_by_username/
• /api/v1/security/get_rls_by_role/

that retrieve users, roles, tables and rls from Metadata tables (using the SQLAlchemy package), convert all filters of type Base to Regular and aggregate the filters with respect to the defined group key value. Obviously considering only the row level securities enabled on that specific user or role.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

BEFORE: no endpoints to retrieve RLS configs made by Row Level security settings page

AFTER:

TESTING INSTRUCTIONS

Create an user with a specific role and related RLS, check if endpoints return correct output.

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[github-actions]

Congrats on making your first PR and thank you for contributing to Superset! 🎉 ❤️

We hope to see you in our Slack community too! Not signed up? Use our Slack App to self-register.

[michael-s-molina]

Thank you for the PR @frlm. I'm not sure if you are aware but we have the following RLS endpoints. Are they not sufficient for your use case?

[frlm]

Thank you for the PR @frlm. I'm not sure if you are aware but we have the following RLS endpoints. Are they not sufficient for your use case?

Hi Michael,
thank you for your interest in my SIP request, I know there are new endpoints to pull RLS information via API, I had read them before implementing the two new endpoints included in this pull request. You will notice that I did not include them within the RowLevelSecurity class because they were not yet present in Apache Superset version 2.1.0. I needed this functionality in the version I am using in a specific production environment. However to explain the reasons why I think it is necessary to add these endpoints I will use /api/v1/rowlevelsecurity as an example. In particular if we read the json argument:

"result: [
    {
      "changed_on_delta_humanized": "string",
      "clause": "string",
      "description": "string",
      "filter_type": "regular",
      "group_key": "string",
      "id": "0",
      "name": "string",
      "roles": [
        {
          "id": "0",
          "name": "string"
        }
      ],
      "tables": [
        {
          "id": 0,
          "schema": "string",
          "table_name": "string"
        }
      ]

we can observe that there is all the information present in the RLS table plus the associated roles but during the embedding requests I observed the following shortcomings:

• the endpoints already present allow you to extract information from the RLS table but do not help you extract the RLS for that specific username or role, generally the Client does not know which role the user is associated with.

• If for that specific user or role there are several RLS filters of the Regular / Base type and with different group key values, it is necessary for the Client to carry out all the logical aggregation operations (AND, OR) to generate the list of dictionaries used later in the endpoint body /api/v1/security/guest_token/.

{
  "resources": [
    {
      "id": "string",
      "type": "dashboard"
    }
  ],
  "rls": [
    {
      "clause": "string",
      "dataset": 0
    }
  ],
  "user": {
    "first_name": "string",
    "last_name": "string",
    "username": "string"
  }
}

This leads to greater difficulty on the Client side in using the tool via API because it must understand and manage any updates on the Superset side on how the settings relating to Row Level Security are managed.

[michael-s-molina]

You will notice that I did not include them within the RowLevelSecurity class because they were not yet present in Apache Superset version 2.1.0. I needed this functionality in the version I am using in a specific production environment.

In scenarios like this, the best approach is to contribute to the master version, to ensure the contribution will be available in subsequent releases, and wait for a minor version of your current release that includes the new feature. An alternative is to just implement this feature locally for your deployment but you'll need to support it when upgrading.

the endpoints already present allow you to extract information from the RLS table but do not help you extract the RLS for that specific username or role, generally the Client does not know which role the user is associated with.

If for that specific user or role there are several RLS filters of the Regular / Base type and with different group key values, it is necessary for the Client to carry out all the logical aggregation operations (AND, OR) to generate the list of dictionaries used later in the endpoint body /api/v1/security/guest_token/.

I'm pretty sure we can resolve these use cases by a combination of filters (q request parameter) and token augmentation if the required information is not there already. I'll ping some folks that know more about the embedded feature and can help you. @rusackas @lilykuang @betodealmeida @yousoph

[frlm]

You are right, I should have released on the master branch. However, I only added two methods within the file /superset/security/api.py; there are no other changes.
I await your feedback, the important thing is that filters of type Basic are transformed into Regular (otherwise they cannot be used) and also that OR aggregations are performed between different RLSs if the group key is the same.

[dpgaspar]

Please use current master for any change/PR

[rusackas]

It looks like this is merging into master now.

[rusackas]

@frim this seems to have slid under the radar for quite some time. Sorry about that. If you want to rebase the PR, we'll see how it works in current Superset, and review it. Hopefully we can get this across the finish line, but in the meantime, I'll set this to Draft mode while it awaits rebase. Mark it as open for review when you think it's ready. Thanks!