Row-Level Security Blocking User Accessing Analysis

I’m having trouble sharing an Analysis with another user, when the underlying Dataset has had row-level security applied to it. When the user opens the Analysis, they receive the error message:

There is an issue with your dataset rules. Contact your dataset owner for assistance. Error code: DatasetRulesUserDenied

I’ve found that removing row-level security from the Analysis’ source Dataset will allow the user to view and edit the Analysis normally. However as I understand row-level security, it should only affect embedded reports, and therefore shouldn’t be preventing the user from viewing and editing the Analysis via Quicksight. The user in this case has an Author role, Co-owner-level access to the Analysis, and User-level access to the Dataset, which should allow them to view and edit the Analysis.

How can I allow this user to view and edit the Analysis without removing row-level security?

Row-level security applies on the dataset level - meaning that analysis and dashboards using that analysis would be affected irrespective if they using embedding or not. If you want to grant the user full access you would need to add him to the dataset specifying the row-level security rules and specify NULL in the field being used to specify access. Using row-level security (RLS) with user-based rules to restrict access to a dataset - Amazon QuickSight

Thanks! That makes sense.

I think I’m confused, then, as to what username I should be adding to my row-level security dataset. I’ve tried adding the user’s Quicksight Username, the Account Name, Account Name\Username, etc. In all tests, my rule column is NULL, which based on the guide linked above should grant the user access to all rows. However I continue to encounter the error when attempting to view an Analysis secured by the row-level security dataset.

Figured out the problem.

Row-Level Security locks down datasets, only granting users access to certain rows of data in a secured dataset. It does that by comparing the user’s username to the RLS dataset’s GroupName/Username column, and then allowing them access to rows in the secured dataset where the RLS dataset’s value matches a corresponding column’s value in the secured dataset. In our use case, we wanted to grant an internal Quicksight user access to all rows so that they can perform overarching analyses. The problem is that when users are working within the Quicksight UI, it seems that there is no Username being supplied, so Row-Level Security is attempting to match NULL to the GroupName.

In order to grant the Quicksight user access to data, we needed to add a new row to the RLS dataset, where GroupName is NULL and the secured value explicitly identifies the rows they should have access to.

One problem we still have is that we don’t have a way to grant this user access to all rows. That’s because of a built-in restriction to Row-Level Security:

To prevent accidentally exposing sensitive information, Amazon QuickSight skips empty RLS rules that grant access to everyone. An empty RLS rule occurs when all columns of a row have no value. QuickSight RLS treats NULL, empty strings (""), or empty comma separated strings (for example “,”) as no value.

We still need a way to grant a Quicksight user access to all rows in a RLS-secured dataset.

1 Like


This video will help you.


Naveed Ali