Forum Discussion
Ownership Chaining
Hi sthoward0914 ,
Can you explain what you are expecting on Ownership chaining? Is it like from whom to whom the ownership changed over a period of time?
Regards,
Srisakthi
Sure. We've been able to do this in SQL Server, Azure SQL Database, and Synapse forever. It goes like this:
I have user1. I deny select on table1 to user1. I create a view named view1 in the same schema that selects from table1 and grant select on view1 to user1. User1 cannot select from the underlying table, but can select from view1. This allows us to specify what from that table user1 can see and in what format.
Hi sthoward0914,
Your example demonstrates standard ownership chaining in SQL Server, where a user can access a view even without direct permissions on the underlying tables. In Microsoft Fabric, this approach is different due to its deny-by-default, identity-based RBAC model, which enforces permissions for each object at query time. Therefore, users must have explicit permissions on the underlying tables, and access to a view does not bypass these checks. This means the same abstraction pattern isn’t possible. At this time, there is no official documentation confirming support or plans for ownership chaining.
Thank you.
Yes, but that just doesn't do the same thing. Nobody seems to be offering a solution to when we want to draw from an underlying table and shape the data differently for what we want users to be able to see. Ownership chaining isn't really a way to bypass security, but rather is a way to govern it that the current security model just simply does not do. It's not really related to "deny by default" either - it's just a missing feature.
If you know a way to do what I'm saying using the current security implementation, then I'd love to learn it, but as it is, it's just something that is missing.Hi sthoward0914,
Ownership chaining is not supported in Microsoft Fabric Data Warehouse, so the SQL Server pattern of denying access to a base table while granting access through a view will not work. In Fabric, permissions are always enforced on the underlying tables, even when accessed via a view. According to Microsoft’s recommended approach, you must grant users access to both the table and the view, and then control what they see by shaping the data in the view, along with applying Row-Level Security (RLS) to filter rows and Column-Level Security (CLS) to restrict specific columns. For more advanced governance, Microsoft recommends using a semantic model (Power BI layer) where users interact with curated data instead of directly querying tables.
Thank you.
