Skip to main content
Row-Level Security (RLS) is a data security feature that filters data seamlessly at the row level, ensuring users can only see the data they are permitted to access.
Unlike table-level permissions, RLS allows for granular control based on user-specific attributes.

​
Basic Mechanism

The basic mechanism of RLS involves defining a per-table SQL WHERE clause that Wisdom automatically injects into every query that uses that table. This filter can leverage Wisdom-specific custom functions to access information about the user running the query. For example, a policy can be set to only return rows where the user_email column matches the logged-in user’s email address.

​
How the SQL Executor Works

All SQL queries in Wisdom pass through a central SQL Executor module. When a query is initiated, the SQL Executor:
  1. Identifies the tables referenced in the query.
  2. Looks up any RLS policies defined for those tables.
  3. Resolves Wisdom custom functions (such as USER_EMAIL()) into their current values.
  4. Rewrites the query to include the appropriate row filters safely.
This approach ensures that RLS rules are applied consistently, regardless of how the data is accessed.

​
Key Concepts

Understanding the core building blocks of RLS helps in configuring and managing it effectively.

​
Dynamic Filters with Custom Functions

Dynamic filters adapt to the identity of the logged-in user. Policies often rely on Wisdom’s built-in functions to inject the right conditions at query time. Commonly used functions include:
  • USER_EMAIL() – returns the email address of the current user.
  • USER_ATTRIBUTE('attribute_name') – retrieves a custom attribute value for the user, typically synced from a SAML SSO provider during setup.
Example: 
tenant_id = USER_ATTRIBUTE('tenantId')
Variants for other data types include:
  • USER_ATTRIBUTE_INT('attribute_name') – resolves to an integer.
  • USER_ATTRIBUTE_STR('attribute_name') – equivalent to USER_ATTRIBUTE() for strings.
  • USER_ATTRIBUTE_STR_LIST('attribute_name') – maps to a list of strings, for example:
territory_id IN USER_ATTRIBUTE_STR_LIST('territoryIds')
  • USER_ATTRIBUTE_INT_LIST('attribute_name') – maps to a list of integers.
These functions let you define flexible, user-aware conditions without hard-coding values.

​
Entitlements Tables

For more advanced setups, RLS can leverage an entitlements table stored in your data warehouse. This table centralizes user permissions and typically includes columns like:
  • user_email
  • resource_type
  • resource_value
Here’s an example of an entitlements table:
user_emailresource_typeresource_value
john@askwisdom.aiTerritoryUSA
john@askwisdom.aiDepartment*
The * wildcard in resource_value grants a user access to all resources of that type.

​
User Attributes

User attributes, mapped from SAML attributes during SSO configuration, allow policies to reflect organizational properties such as department, region, or tenant.

​
Validation and Administration

Proper validation and administration ensure your RLS policies work as intended.

​
Preview and Impersonation

For testing purposes, you can preview filtered data:
  • Impersonate a user to see the data as they would.
  • Set temporary custom attributes at preview time for troubleshooting.

​
Admin Access Control

By default, administrators bypass RLS filters. To apply the same restrictions to them, go to the Advanced tab in the domain’s settings and enable Enable RLS for admin.
⌘I