Search code examples
c#asp.netauthorizationpermissionsrole

In ASP.NET, what to use to manage roles and permissions assigned to roles?

I am working on a ASP.NET web application. I have this well known issue: each user can belong to one or several roles (admin, public users), and each role can have one or several permissions (can edit, can delete, can upload, etc.) and vice versa. I want to do smth like this: [http://demo.sitefinity.com/Sitefinity/Admin/Modules.aspx?route=GenericControlPanel.PermissionsView`1].

I found these options to implement this:

  • using NetSqlAzMan (but I am not sure it will work with our application, as our users are not stored in the same db than the application, and as we are using forms authentication)
  • implementing my own classes which enable me to do: User.HasPermission / AddPermissionToUser / etc.
  • using 2 role providers: one to manage the roles, one to manage permissions, knowing that these providers will be "linked", because of the m:n relationship between roles and permissions.
  • I am using right now a custom role provider, so another option would be to add the methods to manage permissions to this provider.

I want also to cache roles and permissions for a given user. I think it will take me some time to do this on my own, so what do you suggest me?

Thank you in advance

Solution

  • If you find a good packaged solution for a permissions module out there, I'd like to see it :)

    Generally speaking, the built-in security providers stop after the "identification" and "authorization" part. Once identified, and authorized to access the application, more specific page or function level permissions are up to you to code and manage yourself.

    The level of permissions you describe is actually quite an advanced one to implement. It mirrors access control lists (ACLs) in windows. While it seems fairly straight forward, it is actually quite difficult to code. Once you get into designing it you discover that you are having to implement a "deny" override permission, having to handle multi-level group permission merges, and then having to deal with "special" permissions and such. Then you run into the stuff like "does edit permissions imply view too, and what do I do if they don't have view but do have add"?

    It can be a real mess.

    Before you go implementing permissions at that level of complexity, I'd highly advise you to step back and see if you can flatten your permissions and role/group model a bit. Can you not just get away with having your roles BE the permissions? For example, a role for people who can edit, a role for people who can add, a role for people that can view... etc.

    In most applications, you don't really need full ACL like granularity in the permissions system.

    Once you've defined the appropriate level of permissions your application really needs, you are usually best off rolling a set of custom objects to manage those permissions. I have to say I've never considered using a second linked role provider as a permissions manager before... that's a kinda brilliant idea actually. But I'd still advise against it. The role provider wasn't designed for what you are trying to do and you'd likely have to extend and override the default behavior so much that it would be simpler and more maintainable just to have used a custom implementation from the ground up.