![]() |
![]() |
|||||||||||||||
|
||||||||||||||||
|
![]() |
No push please
A sure sign of an application that has been poorly thought out from a security perspective is one that allows for "push" ownership. At this point you are either saying "right on Max" or "what in the heck is he talking about" so for the moment assuming the latter, and if it is the former just bear with me for a second, here is what I am talking about. In any application with half-way reasonable security users are assigned various permissions to resources and or features. Permissions on resources might allow a user to access or edit a resource and permissions on a feature might alllow a user to use or modify the feature. Obviously permissions are only useful when only certain users can modify them and this is where the concept of "ownership" comes in. The "owner" of a resource or feature is, in short, the person who sets and modified the permissions for other users to access the resource or feature. So given that it's a rather important role. So who exactly is the owner of a resource or feature? Normally the first owner of any resource would be the person who created the resource in the first place. It kinds of makes sense to have the person who created a resource to be the person to control access to it, at least initially. But what happens when the ownership needs to change, if, for example the user who was the owner of a resource left the company, or area of the company, went on leave, retired, etc.? In this situation another user "takes" ownership from the first user. How exactly a user may take ownership varies by system and application. In some environments the user relinquishing ownership must enable a certain permission on the resource to allow the ownership to be taken by the second user, in other setups the new owner must be part of a special, Administrators type of group to take ownership from another user. The key word here though is "take" ownership. Sadly there are systems that rather than letting ownership be taken offer it to be "pushed" instead. In such a system the owner of a given resource or feature can push ownership onto another user. This type of system is deeply, deeply flawed. Inherent in the concept of ownership is responsibility. If you control access to a resource then you are responsible for access to the resource. The act of "taking" ownership makes the concept of knowing responsibility explict. Allowing ownership to be "pushed" breaks this basic contract and it's entirely possible and most often the case that the owner of a resource may not know that they even are the owner of the resource, they certainly never took any action to get ownership. Practically speaking the user/group security of an application that allows ownership to be pushed on unsuspecting users is compromised to the point where I think it's justified to say that it's non-existent. If you can't properly assess responsibility then you can never really know who has access to what and when and in the event things go awry you won't know how to fix it, who can fix it and most importantly how to prevent it happening again. The blithe remark I have often heard given as an excuse for allowing ownership to be pushed is that it makes things "easier for the users". This is rubbish. The concepts of ownership and responsibilities are not foreign concepts to adults and if the security interface to an application is too complex the answer is not to destroy the usefulness of the security model to fix it. Tags Categories Comments Peter - May 12th 2008 6:09 PM Max - May 12th 2008 6:38 PM |
||||||||||||||
|
Home | About | Blog | Stuff | Contact | Privacy Policy | |||||||||||||||
| © 2008 Max Stocker | ||||||||||||||||