ASP.NET MVC 3 - Security architecture considerations

Question

I am researching security frameworks for an ASP.NET MVC3 application that would have some pretty complex authorization rules in terms who can see data, who can create and edit it. Rules such as - I can only see clients that are part of my company or branch. - If I am out 15 or less days from the day the record was created and my role is of super user then only I can edit all but two fields on that record. After 16 days or more I can only edit two fields.

My initial thought was to use the Enterprise Security Block and just add customized authorizers, but after reading more about the native support for membership based security in ASP.NET, I am not so sure if Enterprise Security Block is necessary. I have not use neither of the frameworks in a real-world application so looking for some collective wisdom on the topic.

Answer 1

You can use Azman - Microsoft Authorization Manager and its related APIs.

It provides you with roles, actions, permissions and many more configurable options.

Azman uses AD to store most of this. It also provides options to store using local XML and/or configuration files.

Answer 2

You can use asp.net security for basic authentication to the site, and you can use it for basic role membership. But since these are site-wide permissions, you will need your own logic to segment users into organizational permissions.

What I've done in the past is use the asp.net membership logic to handle the basic auth stuff, but then keep another structure in your database that maps the user id's to other parameters - like the mentioned organizational level membership, or especially access rights for data-driven structures.

I'm actually surprised there aren't better solutions already built out there for handling more complext membership/permissions situations that many apps need.

Answer 3

This is the problem with complex field level security. There is no real framework to help you with it, because everything is so custom. The best you can do is extract this into some kind of lookup table, and assign each field a custom identifier in the table, then have a set of columns that indicate each security level. Then, you build your business logic so that you pass in a field and conditions, and it simply responds back whether or not to allow it.

THen you have to figure out what "allow" means in your interface. Disable it? Hide it? ignore it?

I don't envy you.

You might find this semi-interesting.

http://bartreyserhove.blogspot.com/2008/12/field-level-security-using-aspnet-mvc.html

Answer 4

You are crossing into more than just direct security concerns here but actually authorization rules AND edit rules. Your auth rules sound quite custom and I feel that you may need to process these rules in your own custom code and then include these Attributes in your own view models.

Im not aware of any frameworks that will give you this by default as these are very custom editing rules. You could call these claims and when you login go against a claims based framework such as windows identity foundations (WIF) but you will still need custom IF stmts to allow editing in your view based on properties you set in your ViewModel such as CustomerViewModel.AllowAddressEdit. Your view needs to then check this property to display DisplayFor or EditorFor. However you should also check these values on postback to ensure a user hasn't just injected values to hack your app.