Centralized RLS Setup

Centralized Row Level Security in Zing lets you control what data each user can see based on that user’s attributes and conditions you specify.

Centralized Row Level Security in Zing lets you control what data each user can see based on that user’s attributes and conditions you specify.

Once set up, centralized RLS applies for all user roles (viewer, member, editor, admin), and all query modes (natural language querying, visual querying, SQL IDE).

Centralized RLS differs from simply specifying a user-specific filter when you’re creating question, because it applies the row level filtering as a pre-step, before any query is run.

With centralized RLS, the RLS conditions are always enforced and a user cannot remove the RLS filters like they could if you used lookup tables and user-aware filtering alone. This means even users with an editor role, or those who copy a question and edit it wouldn’t be able to remove the centralized RLS.

When a user is logged in to Zing (or is authenticated in embedded mode), they have an identifier. That identifier and other attributes of that identifier (as specified in a lookup table) are used dynamically at runtime to compare against the conditions you specify.

Note:
  • RLS conditions are applied at a table/view level by specifying a SQL condition which would evaluate to TRUE for the rows a user will be able to see.
  • Tables/views without any condition specified will have all rows visible to all users.
  • Only administrators of an organization can set up or modify centralized RLS.
  • Centralized Row Level Security conditions apply to all new and existing questions and dashboards.
  • You should verify with a sample question that your RLS conditions are set correctly and working as you expect.
  • RLS is compatible with all Zing functionality.

 

Setting Up Centralized Row Level Security

  1. Create a data source then click ‘Settings’ and ‘Row Level Security’

  2. Turn on RLS and define a lookup table for user attributes. You’ll have one column indicating the user’s identifier (email), and other columns which will be used as dynamic lookups for that user’s attributes.


    Note: this is a live check so updating this table will update the user’s attributes and resulting rows shown on queries that rely on RLS.

  3. Click on a table or view from the list on the left, and then specify the condition which should evaluate to TRUE if a user is to be shown that row, and FALSE if they shouldn’t see that row based on the condition you specify. For instance:

4. Click ‘save’ and your RLS conditions are immediately applied.

5. Check that the RLS conditions you’ve set are working as you expect, and