Forum Discussion
Resolver IRLS, OLS and Field level security in powerbi
Hi sanjanarama,
To dynamically implement Row-Level Security (RLS), Object-Level Security (OLS), and Field-Level Security (FLS) in Power BI, start by defining relationships between the User Table, Object-Level Security Table, and actual data tables based on the Permission Set ID. For RLS, create a role in Manage Roles using a DAX filter like [UserID] = USERPRINCIPALNAME(), ensuring users can only see the data assigned to their Permission Set ID. For OLS, use Tabular Editor to restrict access to entire tables by filtering the Object Level Security Table to check if a table name exists in the user's assigned permissions, dynamically controlling visibility.To enforce FLS, create a calculated column or dynamic measure that checks if a user has permission to view a specific column, filtering the Field Level Security Table for matching Permission Set IDs and using CONTAINS logic to restrict access dynamically. By applying these techniques, when User 1 logs in, they will only see data related to their permissions, such as the father's name column from Table 4, ensuring secure and dynamic access control in Power BI.
Super UserHi sanjanarama,
Following is one way to dynamically enforce object‐ and field‐level security with your three tables. The basic idea is to implement dynamic row‑level security (RLS) on the basis of the logged-in user and then "join" (through relationships or DAX lookups) the user's allowed permission sets to the object-level and field‑level security tables. For instance, you can establish a connection between your User table and the security tables on "Permission Set ID." Next, create an RLS role that filters the User table based on a DAX expression like:
[UserID] = USERPRINCIPALNAME() // or an appropriate mapping to the current user
Once that’s in place, you can create measures that check whether a given field should be visible. For instance, to display the values in table4.fathername only if the current user’s permission sets include access to that column (as defined in your Field Level Security table), you could write a measure like:
Visible table4 fathername =
IF(
COUNTROWS(
FILTER(
'FieldLevelSecurity',
'FieldLevelSecurity'[Column access] = "table4.fathername" &&
'FieldLevelSecurity'[Permission Set ID] IN VALUES('User'[Permision Set ID])
)
) > 0,
[table4.fathername], // your measure or column from table4
BLANK()
)
In this example, if the logged‑in user (via the filtered User table) has a permission set that allows access to “table4.fathername” (for instance, if they belong to permission set “c”), then the measure returns the field’s value; otherwise it returns BLANK(). You can use similar patterns to control which tables (object-level) and which columns (field-level) appear in your report visuals.
🌟 I hope this solution helps you unlock your Power BI potential! If you found it helpful, click 'Mark as Solution' to guide others toward the answers they need.
💡 Love the effort? Drop the kudos! Your appreciation fuels community spirit and innovation.
🎖 As a proud SuperUser and Microsoft Partner, we’re here to empower your data journey and the Power BI Community at large.
🔗 Curious to explore more? [Discover here].
Let’s keep building smarter solutions together!
Resolver Ican you send a pbix file, im unable to implement the solution