Search code examples
asp.net-mvcasp.net-membershiproles

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 dozens 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?


Solution

  • 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.