Row Level Security

[Amik_singh]

When implementing dynamic RLS using the USERPRINCIPALNAME() function on a dimension table, what unexpected data visibility issue can occur if an active one-to-many relationship exists from the secured dimension table to a large, unsecured fact table, and the dimension table has an active relationship to a separate, smaller bridge table?

[Kmaha986696]

This can cause users to see more data than expected. Even though the RLS rule is defined correctly on the dimension table using USERPRINCIPALNAME, the issue comes from how filters move through the model. When the secured dimension has an active relationship to a large fact table and also another active relationship to a smaller bridge table, the bridge can introduce extra keys into the filter context. Those keys can then flow back into the fact table and expand the result set. As a result, fact rows outside the user’s intended access can become visible, without any warning or obvious sign that something is wrong. This is most common in models with multiple active or bidirectional relationships and is easy to miss unless you carefully test using View as role.

[Amar_Kumar · Accepted solution]

@Amik_singh The unexpected issue is an Incomplete RLS Propagation due to Relationship Ambiguity. If the DAX expression for RLS does not correctly account for the bidirectional filtering (or filter propagation settings) across both the fact and the bridge table paths, the user might see some fact data filtered correctly, but the relationships involving the bridge table could inadvertently expose related records that should have been masked, thus bypassing the intended security filter on the secured dimension table.