Strategy for handling application permissions using Entity Framework 4.1

First, I am using EF 4.1 and utilizing the Repository and Unit Of Work patterns. We are building a web applcaition.

I am beginning my project using the Code First approach for EF 4. Right now, the database doesn’t exist. So, I am trying to come up with a strategy to handle what data a user has access to and where that l开发者_StackOverflowogic should sit in my framework.

Let’s say a user logs into the system and wants to create a user for the system. That form has a field to put that new user in some sort of role. The user tasked for creating this “new user” can only see certain types of roles (User, Creator, and Viewer) but we know that an Admin role exists, but this user doesn’t have access to it. When I call the service to give me that list of Roles, do I want to pull all the roles back, then build a new list based on some sort of permission set?

I am struggling with the idea of have some of this logic in my Repository, but really don’t think it fits there.

The security should be on multiple levels, but I think all would be higher than the repository. Your UI/Menuing shouldn't expose functionality the user doesn't have access too, but you should also check on the server, probably in an application service layer that the user has access to perform the action they are attempting.

In the case of the user roles, you could build the role relationships into your data model, but I would bring them all back from the database and cache them and filter the list with code logic. But the question is how do you know what roles a user can add, or not add? You could use a specific number, leaving gaps, and only allow people of a certain role to create users of a role equal to or less than their own role.

For instance:

RoleID    Role
     1    Peon
     5    Common Folk
     10   King
     15   Supreme Master of the Universe

So maybe only Kings and SMU's have the ability to add new users. SMU's can create other SMU's, Kings, Common Folk, and Peons. Kings can do the same, minus SMU's. The gaps in the ids give you the ability to add more roles later without renumbering.

Your controllers can have different Authorize attribute decarations on the methods, enlisting the roles the users of which can call into w/o an exception being thrown by the mvc framework.

http://msdn.microsoft.com/en-us/library/system.web.mvc.authorizeattribute.aspx