Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Scenario: a large existing system (~300 tables, 500 stored procs, 200 views and a code base of several 100k lines) with most security level stuff in stored procedures needs to be refactored (for maintainability reasons and just availability of skills more will likely be moving to the C# layer, as well as we are hoping for performance since we'll be able to better control what gets pulled when better).

Entity Framework is something we are seriously considering to make things more easily extensible (inheriting the backend schema from a base class for example without having to track down a massive join yourself each time).

Question: how do you handle security with Entity Framework? The examples I've seen where just how to get your model/data model to handle service wide security (tokens for can this guy login? types of things). How can you say a normal user can see these 3 fields on a class but an admin can see these 10? These fields could be logically other classes tables (eg. a particular customers orders). How about things like "this post is read"? Do you just add a list of "haveRead" people to the class or is there a smarter way to get EF to return different versions of the same object depending on who you are? Is there a way to get EF to do this for you without needed a lot of logic in stored procs? If not how do you manage performance (say a person can see a single object and you hit the model for a list of objects then do the filtering higher up in C# meaning you might be getting 1000's of items but only passing on 1 to the client). Can you lazy load individual fields so that if only weak users are making requests all the admin fields don't get pulled over from the database?

share|improve this question
I have some ideas but not at my computer at the moment. I might be off base with my response as I am somewhat new to MVC framework. One thing that comes to mind is using viewmodels you can have a viewmodel for users and admins. – Terry Mar 5 '14 at 21:31
Terry good suggestion. My concern though is this moves security from the DB to the C# layer. Maybe not a huge problem though I suppose but it means that 3rd parties will likely have to have access to your ViewModels or higher level API (and be forced to use them) rather than being able to bake there own model etc from a database. In our case we host all the databases so we'd be fine with that restriction but I can see it being a problem if you shipped your db and then people couldn't just connect to the db for reporting and such since no security|visibility logic exists. – Mike Apr 23 '14 at 23:57
Hey Mike, did you come up witht the conclusion on how you are going to handle this. I am having the same problem. – codebased Oct 8 '14 at 0:13
@codebased we moved away from looking at ORMs: basically doing our own generic methods so we have fine control over batching. I think how we'd go about it assuming EF doesn't support it is add a mapping layer above EF: essentially when serializing the object out to the webservice we'd only serialize fields that the user has access to. This would require either a second fetch to the database to find out which fields they should be able to see or "role" attributes on the fields and caching the roles the user has on the C# side. Eg: "ReadDetails": means fields marked as [Details] get serialized. – Mike Nov 10 '14 at 21:12
@Mike thank you. I am taking an approach to add a Security layer on the top of result set that I get from ORM. With the help of Identity Management in .Net 4.5, I will be identifying the person and customise json outcome. – codebased Nov 10 '14 at 23:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.