How far to 'drill down' roles in a .NET MVC application?

I've written a few complex MVC applications which are all role based and use .NET Membership. On my first project I used roles with structure similar to this:

• Admin
• Manager
• Approver

I quickly discovered that wasn't very scalable, for example a customer would say "I want specific user x to have all manager privileges but not delete". I would then have to put a hack in the controller for that user.

Therefore, my second implementation led to this role structure:

• CanCreate
• CanDelete
• CanEditAll
• CanEditOwn

This approach then led to literally doze开发者_StackOverflow中文版ns of roles based on whether they could edit particular items globally or just their own etc. It also leads to a lot more controller actions and considerably more code - though maybe thats just the case in a complex application!

My question is, am I approaching this in the correct way, and are there any good online resources on the "correct" way to approach complex applications with loads of roles. Am I doing this correctly?

Indeed it's very interesting topic and I found myself struggling with the same problems as you do.

I read Derick Baileys interesting blog about that "Don’t Do Role-Based Authorization Checks; Do Activity-Based Checks" : http://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/

but had not time to experminet it myself.

A year on from this question I handle things a different way across projects. I'm now sticking to the classic roles of:

• View
• Edit
• Delete
• Add

BUT the action methods themselves return data like this:

var order = or.MyVisibleOrders().FirstOrDefault(x => x.Id == Id);

The logic for what is viewable and what is not is then handled by roles in the repository. The database will essentially never be queried for the restricted items in the first place.

Basic stuff but felt I should follow up on myself.