Ownership Chaining

[sthoward0914]

Is Ownership Chaining not supported in Fabric Data Warehouse? If not, is there a plan to implement it?

[v-saisrao-msft]

Hi @sthoward0914,

Checking in to see if your issue has been resolved. let us know if you still need any assistance.

Thank you.

[sthoward0914]

Sorry, I'm on vacation with very spotty internet connectivity.

I can accomplish the task that way, yes, but is the solution Microsoft has offered the best solution? No. It's a lot of extra work in administration for reasons nobody seems to be able to explain. So it's a technically correct answer, but still suboptimal from an administrative perspective. So I got the answer, but an disappointed that is the answer.

[v-saisrao-msft]

Hi @sthoward0914,

Currently, this is a design limitation in Fabric Data Warehouse rather than a best practice, and it results in extra administrative work compared to traditional SQL Server methods. The approach recommended by Microsoft is the supported option for now. If this behavior affects your situation, you might consider posting about it in the Microsoft Fabric Ideas forum; if it receives enough votes, it could be addressed in future updates.

Fabric Ideas - Microsoft Fabric Community

Thank you.

[v-saisrao-msft]

Hi @sthoward0914,

Have you had a chance to review the solution we shared earlier? If the issue persists, feel free to reply so we can help further.

Thank you.

[Srisakthi]

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

[sthoward0914]

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.

[v-saisrao-msft]

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.

[sthoward0914]

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.

[v-saisrao-msft]

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.

[v-saisrao-msft]

Hi @sthoward0914,

Fabric uses a deny-by-default, identity-based RBAC approach, requiring permissions to be explicitly granted for each object. Permissions are checked at query time based on the user's identity. Since access is enforced per object, users must have explicit permissions on the underlying tables, even when accessing data through views. This shows that Fabric does not use ownership-based permission.

OneLake security access control model (preview) - Microsoft Fabric | Microsoft Learn

Thank you.

[sthoward0914]

That doesn't quite do the same thing, though. Column and row based security doesn't either. That seems like a very major thing to just no longer support, thus the question on whether it is being considered for inclusion.