How to Apply Role-Based Row-Level Security (RLS) Differently Across Multiple Dashboards in QuickSight?

I am currently facing a challenge with implementing Row-Level Security (RLS) in Amazon QuickSight and would appreciate your insights.

Background: I have a single dataset that includes transaction data with columns such as brand_id, agency_id, and agent_id. This dataset is used across multiple dashboards in QuickSight.

Requirement: I need to apply RLS differently across these dashboards based on user roles. For example:

  • User A should have access to brand_id X in Dashboard 1 when they have Role 1.
  • The same User A should have access to brand_id Y in Dashboard 2 when they have Role 2.

Current Setup:

  • I have a main dataset with transaction data.
  • I have separate permissions datasets mapping users to their roles and respective brands.

However, I understand that QuickSight applies RLS at the dataset level and not at the dashboard level, which makes it challenging to implement role-specific access controls across multiple dashboards.

Attempted Solution: I tried to use parameters and calculated fields to dynamically filter data based on the user’s role, but I am unsure if this is the most efficient approach or if I am missing something.

Specific Questions:

  1. Is there a way to apply different RLS rules on the same dataset for different dashboards in QuickSight?
  2. How can I dynamically filter data based on user roles across multiple dashboards?
  3. Are there best practices or alternative methods to handle this scenario in QuickSight?

Any guidance or examples of similar implementations would be greatly appreciated!

Thank you for your help!

Hi @manish.chauhan.hs, welcome to the QuickSight Community. Hope these answers help you.

1. Is there a way to apply different RLS rules on the same dataset for different dashboards in QuickSight?

No, Amazon QuickSight currently applies Row-Level Security (RLS) at the dataset level, not at the dashboard level. This means you cannot directly have different RLS rules for the same dataset across multiple dashboards. However, there are ways to work around this limitation.

2. How can I dynamically filter data based on user roles across multiple dashboards?

To dynamically filter data based on user roles across multiple dashboards, consider these strategies:

Separate Datasets for Each Dashboard:

  • Create separate datasets for each dashboard. Apply the appropriate RLS rules to each dataset. This approach can become cumbersome with a large number of dashboards or datasets but provides a straightforward way to enforce different RLS rules.

Dynamic Data Filtering Using Parameters:

  • Use parameters and calculated fields to dynamically filter data based on user roles.
    • Define parameters for user roles.
    • Create calculated fields that use these parameters to filter data.
    • Set up dashboard controls to allow the selection of parameters.
    • Ensure that your RLS implementation respects these calculated fields and parameters.

User-Level Filters with Identity Pools:

  • Leverage Amazon Cognito or IAM to manage user identities and roles.
  • Use these identities to apply user-level filters within QuickSight.
    • Create a permissions dataset that maps users to roles and associated brands.
    • Use these mappings in your dashboards to filter data dynamically based on the logged-in user’s role.

3. Are there best practices or alternative methods to handle this scenario in QuickSight?

Best Practices:

  • Modularize Permissions Management: Keep your permissions dataset modular and easy to update. This will help manage user roles and access more efficiently.
  • Use SPICE Efficiently: Ensure your datasets are optimized for SPICE (Super-fast, Parallel, In-memory Calculation Engine) to handle large volumes of data efficiently, especially when applying multiple layers of filtering.
  • Test Access Controls: Regularly test and validate your RLS rules and dynamic filtering to ensure they work as expected for different user roles and scenarios.

Alternative Methods:

  • Preprocess Data Outside QuickSight: Consider preprocessing your data using AWS Glue or another ETL tool to apply RLS rules before loading the data into QuickSight. This way, you can control data visibility more granularly before it even reaches QuickSight.
  • Custom Visuals and Embedding: If QuickSight’s RLS and filtering mechanisms are too restrictive, consider building custom visuals or embedding QuickSight dashboards into a custom web application where you have more control over the data and user access.

Implementation Example:

  1. Separate Datasets:
  • Dataset A for Dashboard 1 with RLS for Role 1.
  • Dataset B for Dashboard 2 with RLS for Role 2.
  1. Parameters and Calculated Fields:
  • Define role_param parameter.
  • Create calculated field role_filtered_brand_id using ifelse(role_param = 'Role 1', brand_id_X, brand_id_Y).
  • Apply filter in the dashboard to use role_filtered_brand_id.
  1. User-Level Filters:
  • Maintain a user-role mapping table.
  • Use Amazon Cognito to authenticate users and map roles.
  • Apply user-role-based filters in your dashboards using this mapping.

By following these approaches and best practices, you can effectively manage and implement RLS in QuickSight to meet your requirements.

Also, check out this workshop: Workshop Studio

And this learning series : https://www.youtube.com/watch?v=lo4cUa3IwPQ

And this blog: Applying row-level and column-level security on Amazon QuickSight dashboards | AWS Big Data Blog

Did this solution work for you? I am marking this reply as, “Solution,” but let us know if this is not resolved. Thanks for posting your questions on the QuickSight Community!