I have a situation where I need a finer grain security within my page than what is available with forms authentication, membership and roles.
Here is the setup.
1) I have a fictitious customer form that has the customer's name, address and date last serviced.
2) Users in the Admin group can update every field.
3) Users in the Technician group can only update the last serviced field.
How can I implement this finer grain security?
Solution: First, I can secure my form by the authorize attribute requiring a user to be within one of these two roles. Then, within my view, I could check the user's role. If the user is in the Admin role, then the view will display edit fields. If not,
then the view will display an edit field for the last serviced field and display fields for everything else.
1) Does this sound like a reasonable way to handle this?
2) Is there a better/alternate way to handle it?
3) Does this break the separation of concerns MVC offers because of the logic in the view?
1) To me this sounds like a reasonable way to handle this
2) An alternate way is to create an editor template for your view model to keep your view cleaner
3) It does not break the SoC because your controller is telling the view with the Authorization filters basically "look these roles can do this and that so it is up to you how you are how going to translate that into widgets"
Give a man a fish and you will feed him for a day. Teach a man to fish and you will feed him for a lifetime.
Marked as answer by Tom A. on Aug 26, 2010 02:55 PM
If the user is in the Admin role, then the view will display edit fields. If not, then the view will display an edit field for the last serviced field and display fields for everything else.
Tom A.
1) Does this sound like a reasonable way to handle this?
Yes,but not enough. Security only through obscurity does not solve much ....
Tom A.
2) Is there a better/alternate way to handle it?
Yes.
a) You can have 2 views - one for admin , one for technician (and maybe third for visitor ). Return different views from controller action.
b) Please put into model also the logic. Verify the user role, and , if a non-admin tries to change a field that is NOT "last serviced" , throw an exception and log this exception.
Tom A.
3) Does this break the separation of concerns MVC offers because of the logic in the view?
I do not think so. But I emphasize the 2b)
Suppose that a technician that is also some kind of hacker see the source of his page . From how you genereate the edit for "last serviced" he figures how to generate the fields for other fields. He saves his page with multiple edit fields on a local html,
fill the fields and submit. IF you do not put ALSO logic into model , then the application will happily modify the fields.
Please put into model also the logic. Verify the user role, and , if a non-admin tries to change a field that is NOT "last serviced" , throw an exception and log this exception.
I think this is excellent advice.
Something that I recommend to developers is not to use the same model for an admin (who has full read+write access) and a non-admin (who has limited write access). If you present to non-admin users a model that has only properties you expect them to be
able to access, then you've cut off one way for bad data to get into the system, as there's no place to
store the malicious data.
Since in your case you want a model to be partially mutable, it may make sense to split this into two models: one that stores read-only data, and one that stores read+write data. The idea here is pretty much the same as in the previous paragraph. If you're
only storing the read+write model back to the database (and if its data is meant to be accessible to non-admin users) and leaving the read-only model alone, then you're cutting off that avenue of attack.
Marked as answer by Tom A. on Aug 26, 2010 02:55 PM
Tom A.
Member
7 Points
6 Posts
Fine Grain Security in ASP.Net MVC
Aug 24, 2010 03:20 PM|LINK
Hi,
I have a situation where I need a finer grain security within my page than what is available with forms authentication, membership and roles.
Here is the setup.
1) I have a fictitious customer form that has the customer's name, address and date last serviced.
2) Users in the Admin group can update every field.
3) Users in the Technician group can only update the last serviced field.
How can I implement this finer grain security?
Solution: First, I can secure my form by the authorize attribute requiring a user to be within one of these two roles. Then, within my view, I could check the user's role. If the user is in the Admin role, then the view will display edit fields. If not, then the view will display an edit field for the last serviced field and display fields for everything else.
1) Does this sound like a reasonable way to handle this?
2) Is there a better/alternate way to handle it?
3) Does this break the separation of concerns MVC offers because of the logic in the view?
Thanks,
Tom
Forms Authentication ASP MVC 2.0 mvc security
gabriel.loza...
Contributor
3583 Points
800 Posts
Re: Fine Grain Security in ASP.Net MVC
Aug 24, 2010 07:23 PM|LINK
1) To me this sounds like a reasonable way to handle this
2) An alternate way is to create an editor template for your view model to keep your view cleaner
3) It does not break the SoC because your controller is telling the view with the Authorization filters basically "look these roles can do this and that so it is up to you how you are how going to translate that into widgets"
ignatandrei
All-Star
137682 Points
22147 Posts
Moderator
MVP
Re: Fine Grain Security in ASP.Net MVC
Aug 25, 2010 04:12 AM|LINK
Yes.
a) You can have 2 views - one for admin , one for technician (and maybe third for visitor ). Return different views from controller action.
b) Please put into model also the logic. Verify the user role, and , if a non-admin tries to change a field that is NOT "last serviced" , throw an exception and log this exception.
I do not think so. But I emphasize the 2b)
Suppose that a technician that is also some kind of hacker see the source of his page . From how you genereate the edit for "last serviced" he figures how to generate the fields for other fields. He saves his page with multiple edit fields on a local html, fill the fields and submit. IF you do not put ALSO logic into model , then the application will happily modify the fields.
levib
Star
7702 Points
1099 Posts
Microsoft
Re: Fine Grain Security in ASP.Net MVC
Aug 26, 2010 02:27 AM|LINK
I think this is excellent advice.
Something that I recommend to developers is not to use the same model for an admin (who has full read+write access) and a non-admin (who has limited write access). If you present to non-admin users a model that has only properties you expect them to be able to access, then you've cut off one way for bad data to get into the system, as there's no place to store the malicious data.
Since in your case you want a model to be partially mutable, it may make sense to split this into two models: one that stores read-only data, and one that stores read+write data. The idea here is pretty much the same as in the previous paragraph. If you're only storing the read+write model back to the database (and if its data is meant to be accessible to non-admin users) and leaving the read-only model alone, then you're cutting off that avenue of attack.