I need to implement flexible AND simple (if such thing exist) and at the same time utilize built-on means if possible

So far I have MembershipProvider and RoleProviders implemented. This is cool but where do I go next?

I feel like I need to add term "Priviledge" and than hardcode those inside application. Users will configure roles to add Privilidges to Roles and assign Roles to users.

Does that sound like a good model? Should I think about adding priviledges at User level on top of adding them to Roles? I might but I envision problems with setup (confusing) and following support.

If I don't do that and some specific users will need lesser priviledges - admin will have to create another role, etc..

Any silver bullet for system like this? And why Microsoft didn't go further then just Membership and Role providers?

Another idea: Leave Roles as "priviledge" holder and hardcode them. Then I can code to those roles inside app using all available markups/attributes, etc - all Microsoft.

Add new entity "Group" and create relationship like this

  • Users
  • UserGroups
  • Groups
  • RoleGroups
  • Roles

This way I can collect Roles into groups and assign those groups to Users. Sounds great and matches other software patterns. But then I can't really implement things inside RoleProvider like:

  • AddUsersToRoles
  • RemoveUsersFromRoles

And some things do not really make sense anymore because they will be hard-coded

  • DeleteRole
  • CreateRole

1 Answer 1


If role-based authorization isn't granular enough for you then consider using Claims-Based Authorization.

A claim describes a resource and activity - sort of like an entry in an ACL, but more flexible, because the "resource" doesn't have to be a physical object, it can be anything you want it to be and can contain any information you want.

In this model, a claim is equivalent to what you call a "privilege", and you group claims into claim sets, which is roughly equivalent to what you're calling a "role". All of these APIs and more are already in the System.IdentityModel namespace.

Of course you mention MembershipProvider and RoleProvider and if you are trying to cram this all into the ASP.NET membership model (as those names imply), then just forget about it. If you want to use those provider APIs then you have to do it their way, and their way does not get any more granular than the concept of a role.

Instead, in ASP.NET, the concept of a "privilege" is actually encoded at the action or operation level, where you declare which roles are allowed to execute that action. This is really a lot easier to deal with in ASP.NET MVC where you just slap an [AuthorizeAttribute] on controllers or controller actions; in "old-school" ASP.NET, you're handling events, so authorization either tends to be either ad-hoc or at the page level (or both).

  • Lot of great information, thanks! App is actually Silverlight app with portion of server exposed as WCF RESTful service. Claims-Based looks interesting but I didn't notice concept of user and autorization inside of it. Interesting article I just found: geekswithblogs.net/shahed/archive/2010/02/05/137795.aspx
    – katit
    Jun 14, 2011 at 20:58
  • @katit: Virtually all authentication/authorization in .NET is based on the IPrincipal interface. If you're doing claims-based authorization then you use an IClaimsPrincipal for that, and cast the IPrincipal to IClaimsPrincipal when you want to do claim checks. You'll be writing a lot of your own code if you want to fit it in with (for example) Forms Authentication, but obviously it can be done (as per the link).
    – Aaronaught
    Jun 14, 2011 at 21:06
  • the question is.. Maybe it's easier to just add another "Group" level to membership/role providers or write own provider? Pretty much same amount of work as implementing Microsoft ones
    – katit
    Jun 14, 2011 at 21:17
  • 3
    @katit: Famous last words. Don't invent your own unless you have a very good reason to invent your own ("it seems easier" isn't a good reason; it only seems easier when you've had no direct experience and thus have no ability to judge the amount of work required).
    – Aaronaught
    Jun 14, 2011 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.