http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660ParanoidPenguin, Yes, EntityGroup is the way to go here. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment30http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment30Tue, 20 Nov 2007 11:26:23 GMTGreat article - thanks! Sorry if this is a poor question, but how would you deal with scenarios like certain users only being able to view customers over a certain age threshold? Would you use the EntityGroup? http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment29http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment29Tue, 20 Nov 2007 11:25:08 GMTLet's say we need to change ownership rules. We first need to find all the EntitySecurityKeys that were created for the old rule. Then we test to ensure that all the security info created from the old rule exists for all these keys (otherwise, throw an exception). Then we find any additional security info linked to these EntitySecurityKeys, which was used to augment the rule-based security info. We either store this info in X, or throw an exception if any such info is found. Then we wipe out all those EntitySecurityKeys, create new ones based on the new ownership rule, and optionally merge X into these new keys. Does this make sense? If so, are you happy with this approach? http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment28http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment28Mon, 19 Nov 2007 21:05:52 GMTIn other words, if I have a solution that I can implement externally vs. solution that I need to mess around with the code with, I would rather go with the first. This way, there is only a single set of rules, and the only thing you need to do is operate on the data. This make it simple to build things like Why(), and it make it simple to understand what is going on. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment27http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment27Mon, 19 Nov 2007 19:49:22 GMTIn other words, if I have a solution that I can implement externally vs. solution that I need to mess around with the code with, I would rather go with the first. This way, there is only a single set of rules, and the only thing you need to do is operate on the data. This make it simple to build things like Why(), and it make it simple to understand what is going on. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment26http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment26Mon, 19 Nov 2007 19:49:22 GMTChanging a lookup table is easy, it is just data. Changing the equation means changing code and has further implications http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment25http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment25Mon, 19 Nov 2007 19:48:06 GMTCan you elaborate on that? If the equation changes, the lookup table needs to change as well... http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment24http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment24Mon, 19 Nov 2007 19:38:05 GMTThe problem is that the equation requires changing frequently, while the lookup table is a more solid approach to changes. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment23http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment23Mon, 19 Nov 2007 19:16:55 GMTMy worry wasn't so much about performance as duplication. It's like having a clunky lookup table instead of an elegant equation. Wouldn't things get complicated if you decided to change the rules of ownership after multiple EntitySecurityKeys originally created for ownership rules got their rules modified for reasons other than ownership rules? Getting the two rule sets (the one-off vs. the equation-based) mixed could get messy. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment22http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment22Mon, 19 Nov 2007 19:00:44 GMTBob, Importance is for deciding whatever to allow or revoke base on several permissions. Check the algorithm for that http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment21http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment21Mon, 19 Nov 2007 17:07:14 GMTAyende, thanks for all your great information....quick question for you: Can you explain the "Importance" attribute, and what your using it for? And I echo Marco's comment that a sample/demo app would be much appreciated! http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment20http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment20Mon, 19 Nov 2007 14:22:16 GMTLuke, My main concern here is the simplicity of the model, so I want to have as few special cases as possible. I don't think that you are an order of magnitude higher, no. It is entirely possible to have million or more security records. The nice thing about it is that we don't care. DB are really fast in making sense of all that data, especially with predictable queries and good indexes, and caching on top of that should make it easier still. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment19http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment19Mon, 19 Nov 2007 02:56:22 GMTYour Why() method is, sadly, brilliant. I understand the need to not output sensitive information which could make it into a UI element or log on a client's machine, but simply doing nothing is a terrible choice that has cost software developers and IT pros countless hours of unnecessary frustration. One thing you do not take into account is what to show the user if he/she is not allowed to view particular data. Often the answer is "nothing" or "hide the field", but sometimes you might want to put "***" or something like that. One could argue that this is information for the view, but it would be good to be able to see security information closely linked with what the user sees, at least in the security admin UI. This might even tie into your Why() method above -- it would be good to have technical reasons and business reasons for why something cannot happen. Perhaps this would have helped you in the story you mentioned, where the code was doing exactly what it wanted to do, something that was in contrast with the business needs. > ... all we need to do is define an action that would add the owner's permissions explicitly to the entity ... This bothers me. It seems you would need a potentially very large number of custom EntitySecurityKeys, as I see no way to attach permissions without it. If one thousand users can do special things to items they own in a hundred different tables, that's up to 100,000 records that are potentially very simple calculations. Let's say that users can, on average, see 10 more columns on records they own. Now we're up to a million security records. Perhaps I'm overestimating by an order of magnitude, but the idea of having so much duplication bugs me. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment18http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment18Sun, 18 Nov 2007 19:05:20 GMTcomlin, Well, how are he going to get the connection string, first of all? He would need to be able to break DPAPI, since they are encrypted using it. But even assuming a nefarious person managed to get to this level, why the hell am I trying to close the barn door after the horse went away. I'll have a full post about it shortly. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment17http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment17Sun, 18 Nov 2007 17:32:31 GMTShadi, Partial views are already handled in this scheme, the UI needs to check for operations such as Account.ExpectedRevenue.View and use this information to display or hide fields. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment16http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment16Sun, 18 Nov 2007 17:18:21 GMTKnave, the enum is an issue for maintainability, as already mentioned, but it also suffers from another problem, the inability of a user to define their own operations and extend the system. If performance is a goal, there are very few things that can beat caching. Especially if you want to cache just the result, not the way. So you can cache if I can look at an account, for instance. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment15http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment15Sun, 18 Nov 2007 17:16:24 GMT@Ayende, What would you say if I give you a real world scenario: 1. Server running Microsoft Windows hosts a web site which includes your security features. 2. Separate server hosts database. Well, common thing isn't it? We are pretty sure that the first server(it's on the Internet) would be hacked sooner or later and the hacker will acquire admin privileges. And all we have is your "entity security" inside the BL, who needs it anyway, you will take the connection string and perform all the malicious actions inside the database! I see two ways to handle this situation: developing an app server to process queries or building security infrastructure inside DB using stored procedures or row-level security. What do you think? http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment14http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment14Sun, 18 Nov 2007 17:12:04 GMTShadi, I concur with the maintenance issue. However since the permissions module will be very heavily stressed, we often need to consider performance factors into it. Having 1 db row versus 6-7 rows per user to store a single module/entity's permission will definitely give you better performance during read/write operations. But this is just the easy part. In each of our modules, we often execute check permissions code for that particular function. But when coding for the UI layer, you will often need to pull out majority of the permissions data, i.e. you should not see that delete button if you're not suppose to see it. Even with caching applied that will take a very heavy toll on the overall system response. Just my two cents. KnaveT http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment13http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment13Sun, 18 Nov 2007 15:17:02 GMTAyende, Excellent post. I'm just thinking loudly on how you can support partial entity view permissions. In other words, one user can view certain entity information that others can't in cases where you have your entity properties on one screen. Is it by having the entity property name in the database and you filter your results according to it. Also, what would be the case in screens where you have more than one entity. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment12http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment12Sun, 18 Nov 2007 10:56:58 GMTKnavet, If i'm not mistaken, depending on the operation name is more maintainable than having an Enum inside your code, where you need to update everytime you add a new method to the entity in question. Besides that you need to maintain a seperate enum per entity. In addition, implementing an admin console is easier through reflection and custom attributes. Just thoughts. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment11http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment11Sun, 18 Nov 2007 10:47:35 GMTAs a suggestion, you can make use of Enum flags to combine these operations into a single line. e.g. public enum AccountOps //values must be multiples of 2. { CanView = 1, CanEdit = 2, CanViewSpecialData = 4, CanViewTotalRevenue = 8 ... } And when storing the configurations as one, you only need to combine them. AccountOps ops = AccountOps.CanView | AccountOps.CanEdit; When persisting into your entity, just use an Int32. When checking for permission, you can just take out and compare them like this: bool canEdit = false; AccountOps ops = AccountPermissionController.Get( myUser ); if( (ops & AccountOps.CanEdit ) > 0 ) canEdit = true; return canEdit; http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment10http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment10Sun, 18 Nov 2007 06:42:58 GMTSteve, Account.SomeOperation Account.AnotherOperation You define another operation for that. Think in terms of operations on data, not in terms of whatever it is that allows it to do it. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment9http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment9Sat, 17 Nov 2007 22:44:33 GMTI think your model is severely flawed (due to being entity-based). It is better to define security very close to the views and controllers, rather than the model (entities). This is mostly because that is how the user wants to define security. They may legitimately have reason to access to an entity from one screen and not another, or during one process but not another. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment8http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment8Sat, 17 Nov 2007 22:10:29 GMTwow nice write up. I dont suppose you would be interested in providing a sample project and db to demonstrate all this? It would be great to be able to see this working, and help understand it better. I think entity security in an application is one of those hardly mentioned topics some many dont know the true way of implementing it. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment7http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment7Sat, 17 Nov 2007 21:58:39 GMTI think that I meant copying them to the denormalized table. About the merge, I don't think so, they have distinct resposabilities. An Entity Group is a way to specify permissions for a set of entities, while the key is the set of permissions on a specific entity http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment6http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment6Sat, 17 Nov 2007 21:12:00 GMTYeah I noticed, but since your were speaking of copying the permissions when a new EntitySecurityKey is created and your query at the end only selects based on a single EntitySecurityKey, I thought you were just tracking the parent key for some other purpose. Thanks for clarifying this. Any thoughts about merging EntitySecurityKeys and EntityGroups? http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment5http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment5Sat, 17 Nov 2007 20:12:49 GMTThomas, Did you notice that the EntitySecurityKey has a Parent? That is where the parent goes, so you do get dynamic inheritence of those. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment4http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment4Sat, 17 Nov 2007 20:01:54 GMTCool. Some similar ideas to what we do in our Rails app. http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment3http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment3Sat, 17 Nov 2007 19:31:58 GMTThanks for this well explained security layer! I'm very interested to see how you would implement this with real source-code, especially how to handle the DenormalizedPermissions with write-through caching layer Another idea for your next topics: - Implement a plugin system for the UserInterface (and/or database to allow db changes for each client) Thanks Marco http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment2http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment2Sat, 17 Nov 2007 19:16:35 GMT"If we want to set special permissions on a specific entity, we will create a copy of all the current permissions on the entity type, and then edit that, under a different EntitySecurityKey" This means that changes to the permissions on an EntityType after copying will no longer affect the specific entity. Why this may be useful in some situations, I believe that in most cases you want to use the default entity type permissions (even when they change) and only add or change a few of them. So why not use some sort of dynamic inheritance instead, like you can do in the NTFS file system. Also have you thought about merging the EntitySecurityKey and the EntityGroup concept together? They both define a set of one or more entities and since you have to determine all entity groups an entity belongs to anyway, it wouldn't hurt performace that much, would it? Also, since entity groups are not mutually exclusive like EntitySecurityKeys are, you get some form of permission inheritance thrown in for free... Anyway, this is really a great series so far, so keep the posts coming! http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment1http://ayende.com/2958/a-vision-of-enterprise-platform-security-infrastructure#comment1Sat, 17 Nov 2007 18:17:07 GMT