Permissions/right model/pattern for .NET application

Question

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

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