http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I just found another idea to store object based permissions.. http://www.codeproject.com/useritems/usermgmt.asp http://ayende.com/2513/security-considerations#comment6http://ayende.com/2513/security-considerations#comment6Thu, 21 Jun 2007 12:17:04 GMTSean, Complex scenarios calls for more granular level of security, so I would generally note that in my assert, and act upon it elsewhere. I may have something like: [AllowOnly("Admins")] public class MyController { [AllowEveryone] public void Login() {} } But if this gets more complex than that, maybe it is time to split the container? http://ayende.com/2513/security-considerations#comment5http://ayende.com/2513/security-considerations#comment5Thu, 07 Jun 2007 16:25:40 GMTOren, This is an excellent post. I will be using your Assertion idea on the controllers that you used. I like how readable that is and it's very intuitive. I just got to a point on one of my larger projects that I need to implement really granular permissions. Up to this point it was just checking if they were authenticated or not through a IAuthenticationService like you use above, and checking if they are in one specific role or not. I was starting to use PrincipalPermission attributes on the actions, but this is starting to become a little messy. Then I just started setting the PrincipalPermission attributes on the controllers themselves, although in some cases certain parts of a controller can be accessed by all roles, while others can only be ran by specific ones. That is where it becomes to sprinkle the attributes through my controller. Another thing I need to do is add more logging as you stated. Log4Net is in place, I just need to add entries under the denied actions which should be fairly easy early on. Do you have any reccomendations on how to handle more complex scenarios like that? http://ayende.com/2513/security-considerations#comment4http://ayende.com/2513/security-considerations#comment4Thu, 07 Jun 2007 15:29:18 GMTIn the WinForms app that I work on, we use the approach you first describe, but only for read-access, and only for "root" objects. In this respect, security is an "aspect" that works no matter how you call the DAL. Any more than that, and the problem (for us) becomes that our own business logic cannot do what it needs to do unless the user has permissions. For example, part of the process of attaching an Address to a Customer might be that another record is created (a log entry maybe) in some other location. It does not matter that the user cannot create log records manually - the log should still be created. Sure, we can work around the problem, but it ups the complexity, lowers testability and increases the bug count. The next layer of security is at a higher level, both filtering available client actions (in a similar way to what you described), and hiding data. When the security is close to the UI, it can be defined in terms of the UI (screen-access security). That level of context is not available in the DAL. It also lets the users define security in a way that makes sense to them. The remaining problem is for other modules of the system that do not use the same framework as the main UI. An example is reports. However, reports are their own beast anyway - a summary report may ignore individual record security, and a detail report should definitely not. I am still struggling with that part. http://ayende.com/2513/security-considerations#comment3http://ayende.com/2513/security-considerations#comment3Thu, 07 Jun 2007 13:43:48 GMTNumber 3 is problematic because of the issues I have outlined above. The security would be either in the query itself (give me all customers who have ordered X in Y days that are associated with the current user) or with the controller. I am doing MVC in a web app, btw. http://ayende.com/2513/security-considerations#comment2http://ayende.com/2513/security-considerations#comment2Thu, 07 Jun 2007 04:37:28 GMTOren, Great post, ok, I had to read it twice. Can you explore this more? I remember reading a post you made, I believe about CRUD access, and you had a nice user / group / role scenario going. In your code you are doing this in a controller, looks like MVC. Lets assume this is a smart client where you need to also secure the service. My thoughts have been to have: 1) Security on the client, filtering available actions. 2) Security in the service, doing the same filtering. 3) CRUD security in the DAL as a catch all. Maybe number 3 is overkill, and possibly problematic? One additional bit of complexity, lets say you have a query object that allows you to grab all customers who have ordered X in Y days. In other words you do not have an explicit method for this, but a generic query object. The CRUD security is nice because sensitive (you are not allowed to view this) fields would not be returned as the query would check for read permissions on all requested attributes and not return ones for which you have read permissions. What are your thoughts? http://ayende.com/2513/security-considerations#comment1http://ayende.com/2513/security-considerations#comment1Wed, 06 Jun 2007 23:45:38 GMT