http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660This blog, mostly. Check the other posts about it. Especially "Vision of Enterprise Application: Security Infrastructure" This is not something that I wrote from a reference, but from experience. http://ayende.com/3110/designing-the-security-model#comment15http://ayende.com/3110/designing-the-security-model#comment15Fri, 25 Jan 2008 15:20:25 GMTHi Ayende! I'm always read your posts with big interest! Could you pointed me on the resources which you used for creation of you security framework? URL-s books code libraries /snippets etc. Thank you! http://ayende.com/3110/designing-the-security-model#comment14http://ayende.com/3110/designing-the-security-model#comment14Fri, 25 Jan 2008 15:15:52 GMTMacro, No. That is not the way I would go. You would have several operation for viewing the entity in this case. * View Employee Information * View Employee Salary This match into the concept of the domain better than just allowing view on the salary property. The concept here is not protecting data, but securing operations. http://ayende.com/3110/designing-the-security-model#comment13http://ayende.com/3110/designing-the-security-model#comment13Wed, 23 Jan 2008 20:54:44 GMT@Marco: The easiest way to protect properties would be to extract them into their own nested entity (component), as a side effect, it usually increases entity cohesion. http://ayende.com/3110/designing-the-security-model#comment12http://ayende.com/3110/designing-the-security-model#comment12Wed, 23 Jan 2008 20:34:24 GMT>> Sorry, I don't understand the meaning of "protecting the entities". Indead ReadPermissions can be handled at the repository, but how would you protect some properties (like Salary) or prevent writing a property like CompanyName..Shouldn't that not be handled at Entiity level? http://ayende.com/3110/designing-the-security-model#comment11http://ayende.com/3110/designing-the-security-model#comment11Wed, 23 Jan 2008 20:28:50 GMTBunter, See my next post for an example http://ayende.com/3110/designing-the-security-model#comment10http://ayende.com/3110/designing-the-security-model#comment10Wed, 23 Jan 2008 19:55:23 GMTIt's an extremely interesting topic. Security systems are usually something nobody wants to talk about (or deal with). And in many cases, role based approach works ... with a lot of compromises to the actual security. But I would also like to hear how you push context to the security subsystem while using declarative approach as in your monorail sample. For example if action rules depend on the data action pulls out. http://ayende.com/3110/designing-the-security-model#comment9http://ayende.com/3110/designing-the-security-model#comment9Wed, 23 Jan 2008 19:17:57 GMTFrancois, Security per instance is important, certainly. I shouldn't be able to view another customer's data. Impersonation is a hack on top of the permissions on data mentality. You don't secure data, you secure operations. Those are operations: * View Customer Orders * Add Order * Ship Order * Change Shipping Address * Approve Order They relate to specific data, certainly, but they aren't data in themselves. http://ayende.com/3110/designing-the-security-model#comment8http://ayende.com/3110/designing-the-security-model#comment8Wed, 23 Jan 2008 19:13:18 GMTMarco, Sorry, I don't understand the meaning of "protecting the entities". Can you explain? http://ayende.com/3110/designing-the-security-model#comment7http://ayende.com/3110/designing-the-security-model#comment7Wed, 23 Jan 2008 19:09:48 GMT@Marco, I would wrap my security into specifications and pass those to my repository to resolve and create queries. AddressBook.Find(new MyContactsSpecification(CurrentUser)); Anyone else? http://ayende.com/3110/designing-the-security-model#comment6http://ayende.com/3110/designing-the-security-model#comment6Wed, 23 Jan 2008 19:01:56 GMTBy context, do you mean data-based security where security is granular to an instance of an entity and not affected to a role that the user plays, whatever the instance of the entity it plays the role (performs the use case) against? Are your security issues are related to having to grant extra roles (or rights) in order to have access to non-functionnal infrastructure (read rules)? If so, one approach I've used in the past is to allow impersonation in my security framework so that user can be impersonated to a "system" account, account being able to read security rules. In other terms, I wouldn't allow the user to directly visualize the rules but would definitely grant him some non-functionnal role that grants him the right to query (read) the rules for authorization purposes. Hence, I tend to make differences between Read and View http://ayende.com/3110/designing-the-security-model#comment5http://ayende.com/3110/designing-the-security-model#comment5Wed, 23 Jan 2008 18:54:37 GMTIn the samples you're giving your basically protect running actions, but you don't protect the entities that are used inside that action. How would you protect the entities inside an action? http://ayende.com/3110/designing-the-security-model#comment4http://ayende.com/3110/designing-the-security-model#comment4Wed, 23 Jan 2008 18:41:19 GMTNo, role based security isn't about this, because roles doesn't have context. Do you allow a user to read the rules? In what context? http://ayende.com/3110/designing-the-security-model#comment3http://ayende.com/3110/designing-the-security-model#comment3Wed, 23 Jan 2008 18:14:22 GMTIsn't what Role-Based security stands for anyways? Normally you create roles according to the use cases. http://ayende.com/3110/designing-the-security-model#comment2http://ayende.com/3110/designing-the-security-model#comment2Wed, 23 Jan 2008 18:11:01 GMTVery nice post Ayedne. This one goes in my save stack for the next time I need to implement a security system for a client. http://ayende.com/3110/designing-the-security-model#comment1http://ayende.com/3110/designing-the-security-model#comment1Wed, 23 Jan 2008 17:39:42 GMT