Row Level Security in OneLake (preview). Major limitations?

[FelixL]

Hi, I am reading up on the new upcoming RLS features in OneLake security. I have been eagerly awaiting this feature since the release of Fabric, since we are currently heavy users of RLS in our Power BI solution. 

Until now we have used RLS in Semantic Models, Paginated Reports and Lakehouse SQL endpoints successfully, by maintaining a huge RLS permission matrix for thousands of dimension attributes (individual cost centers, companies, projects, ...) and thousands of Power BI users. The combined total of unique permissions range in the upper tens of thousands. 

This list is then dynamically applied as RLS in the various parts of Fabric, using native RLS in semantic models, and security predicates in the SQL endpoints. So far so good. 

However, the new functionality being released, to allow for an all encompassing RLS solution in all of Fabrics execution engines seem to be extremely limited. Reading the documentation it looks to me that I would have to create one security role per unique RLS rule (ie one for each cost center, ..), and the assign the applicable users in this role. This would mean thousands of security roles on every Fabric item (Lakehouse) I would like to control with RLS. And a huge amount of role assignment work, which is already done my me when maintaining the RLS matrix in an external system. 

Am I correct in my understanding here that there will be no support for creating dynamic RLS roles (looking up the permissions in another table, based on the user id of the accessing user?). This seems to me like a huge oversight, if this is indeed the case? 

Or could it be that the final solution when GA will support this type of dynamic roles? 

https://learn.microsoft.com/en-us/fabric/onelake/security/row-level-security

[v-sgandrathi]

Hi @FelixL,

we would like to sincerely thank @Vinodh247 for the thorough and accurate response provided.
Your explanation addressed the current limitations of Row-Level Security (RLS) in OneLake (preview) very well, and we appreciate the detailed insights shared to assist the community.

We would like to further confirm and slightly expand on the key points:

• As mentioned, dynamic RLS based on user identity (such as leveraging USERPRINCIPALNAME() or similar dynamic filtering mechanisms) is currently not supported in OneLake RLS preview.
• Static role definitions and manual assignments are required, which can indeed be challenging for organizations managing complex permission structures across large user bases.
• RLS enforcement is currently scoped to Delta tables and supported mainly in execution engines like Spark notebooks. Enforcement across additional engines and data formats is expected to improve in future releases.
• Microsoft is actively working toward expanding OneLake's security capabilities, including more granular, dynamic, and portable access control mechanisms, though no specific General Availability (GA) timeline or feature commitments have been officially announced as of now.

We encourage you to continue leveraging the dynamic RLS models within Power BI and Fabric components until broader dynamic support becomes available in OneLake.

We appreciate your feedback and encourage you to submit feature requests through the Fabric Ideas Forum to help prioritize these enhancements.

Fabric Ideas - Microsoft Fabric Community

Happy to help! If this addressed your concern, marking it as "Accepted Solution" and giving us "kudos" would be valuable for others in the community.

Thank you.

[Vinodh247 · Accepted solution]

Yes. There is a significant limitation with the current preview of RLS in OneLake. As it stands, the implementation lacks support for dynamic RLS based on user identity, such as leveraging functions like USERPRINCIPALNAME() to filter data dynamically based on the accessing user.

Key Limitations in OneLake RLS (Preview)

1. The current RLS implementation in OneLake requires defining explicit SQL SELECT statements with WHERE clauses for each role. There's no mechanism to reference the accessing user's identity dynamically within these rules. This means you would need to create a separate role for each unique access requirement, which is impractical for scenarios involving thousands of users and complex permission matrices.

2. Roles must be manually assigned to users, and there's no built-in support for dynamic role resolution based on user attributes or external lookup tables. This manual process can be cumbersome and error-prone, especially in large organizations.

3. RLS rules are only enforceable on Delta Parquet tables within OneLake. If you attempt to apply RLS to non-Delta tables or unstructured data, access is either blocked entirely or not enforced, limiting the applicability of RLS across different data types.

4. RLS enforcement is currently limited to specific Fabric engines, such as Spark notebooks. If data is accessed through other engines or services not supporting RLS, the security rules may not be applied, leading to potential data exposure.

Given your extensive use of dynamic RLS in PBI where you manage a large and complex permission matrix, the current OneLake RLS preview may not meet your needs. Implementing equivalent functionality would require creating and managing thousands of static roles, which is not scalable or maintainable.

That being said, Microsoft has indicated plans to enhance OneLake's security model to support more granular and dynamic access controls, including row and columlevel security that travels with the data across different engines. However until these features are GA, you may need to continue relying on your existing dynamic RLS implementations within PBI and other components of Fabric.​

Please 'Kudos'(Thumbs-up) and 'Accept' as an solution if the reply was helpful. This will also help us close this thread and acknowledge the time spent by community volunteers like us.

[FelixL]

Thank you for verifying and explaining this in detail for me. I will keep my eyes on the development on the OneLake Security functionality, hoping that we will indeed see a more dynamic approach to RLS/CLS for the spark engine going forward. (Fingers crossed).

Thanks!