Row-level security in Entity Framework 4


  • Hi,

    Are there any hooks in Entity Framework 4 that allows implementing row-level security?

    What I basically need is to filter table rows based on the currently authenticated user in a multi-tenant application. I would like to implement it somewhere in my entity model, so that developers would not have to add filtration to all queries.

    For now, I've found the only applicable extension point, which is to wrap ADO.NET provider used by EF. But this level seems too low to me, as I need to change the DbCommandTree already created by EntityFramework, which is error prone.

    I was thinking of the T4 generated templates for ObjectContext child class as an extension point. But the problem is that we are also using Microsoft's DataService class to expose data services, which invokes ObjectContext.CreateQuery() method directly and bypasses my wrapper.

    So, the extension point I need must be somewhere above data provider and beneath object context. But I haven’t found one. Does it exist at all?

    • Edited by Sergey_B Tuesday, August 10, 2010 4:57 PM
    Tuesday, August 10, 2010 11:48 AM


All replies

  • Entity Framework, being a pure ORM, doesn't provide any hooks (like a BeforeQuery event) out of the box.

    I suggest looking at ADO.NET Data Services. This is a WCF-based service pattern that runs on top of EF, and provide QueryInterceptors and ChangeInterceptors to hook into the user queries.

    Tuesday, August 10, 2010 2:32 PM
  • Thank you for reply.

    I already use Data Services to provide access to the data for external applications, and query interceptors were the first candidates to implement data filtration. However, they have several disadvantages:

    1. You have to copy-paste interceptor method for each new entity set, which is error prone.

    2.  Data Service query interceptors do not help if EF model is accessed not via Data Service.

    Tuesday, August 10, 2010 4:55 PM
  • Sergey,

    It appears that what you are looking for is row level security as a piece of infrastructure. I agree that it makes no sense having developers adding filtration to all queries as it is inefficient and a recipe for disaster. The best approach to row level security has to be where it is implemented as an additional layer of security in the same way that firewalls protect the perimeter(at the network level) and LDAP is used at the application level in relation to service availability, functional constraints and single sign-on.

    It is well accepted that at the DMZ Layer, Firewalls, Routing and Protocl Standards are all non functional requirements with respect to application development. Similarly at the LDAP layer, Single Sign-on, Functional Constraints and Service Availability are all non functional requirements with respect to application developmet. At the Data Level, row level security needs to be implemented so that it is independent of any applications that consume the data. To be effective and easy to maintain, row level security needs to be a piece of infrastructure that is also a non functional requirement in regard to application development.

    We have invented some new technology that you may find particularly interesting. Our row level security technology, Data Chamber is highly scalable and comes with a negligible performance overhead. It will also work with any RDBMS... In terms of performance, Teradata performed a benchmarking exercise on Data Chamber on a 400 million row database and the overhead associated with some of the queries was measured in milliseconds

    If you would like to find out more, please feel free to have a look at our site,

    I hope this is helpful to you


    Friday, August 20, 2010 5:39 AM