We always have problems to using role-based in large systems. In such softwares we want superusers to able to set their organization users permissions. We can create many atomic roles and create a console for assigning the roles to the users. Then we have to create many roles, for example:
AddProduct, RemoveProduct, EditProduct, AcceptPurchase, DenayPurchase, ...
In this way, for a medium system we should have at least 50 roles! Then how the admin can assign these roles for each user?
We have two solution at first glance:
To create a table in DB (for example Group) to put between the users and roles. Then admin should create a group of roles then assign a group to multiple user.
Use roles as a group of permissions. For example create a PermissionInRoles table and assign the permissions for each roles then assign the roles to the users.
We soon find the first approach nonsense. And we implement several project with second approach. But now we want to use it in a sivlerlight project besides the WCF RIA Authentication services. It just supports the roles. For example each user instance has an IsInRole method which we implement our IsInPermission method instead.
There is another problem when using RequiresRole attribute for services. I can't and I don't want to put a hardcode role name for each service method.
Know we are so confused about the role-based security design! How can we use it in these situations?
Your concept of "role"-based authorization seems a bit flawed. Then again, that's not uncommon, given that there are various definitions out there that aren't exactly in violent agreement, at least in their finer details. The only thing they all tend to have in common is that the main determinant whether an authorization attempt passes or fails are properties of the user, not properties of the target against which one is planning to execute an action. Beyond this, you probably shouldn't assume too much about what an authorization system actually does if it claims to be "role-based".
For example, in the ASP.NET role-based authorization paradigm that you're using now, the actual "roles" correspond to a fixed (i.e.: known at compile-time) set of operations. For example, instead of the granular "AddProduct", "RemoveProduct", and "EditProduct" permissions that you listed in your original post, one might expect to see a fixed "Product Manager" role. If you want to authorize at a more granular level, then this "pure" role-based approach isn't really suitable, and IPrincipal.IsInRole probably isn't something you should be using at all.
It sounds like you want to authorize granular "operations", with operations being grouped into "roles" via runtime configuration. Some set of "administrative" users would have permissions to manage this configuration. They could create, modify, and delete "roles" as desired, with each "role" being a set of "operations" that are recognized by your application (i.e.: "role" is to "operation" as "group" is to "user"). Your application wouldn't need to have any awareness of the roles. Instead, it would authorize operations. Users would be granted permissions to operations via any of the following:
Administration of the authorizations is greatly simplified when only approach #4 is used, but the actual approach(es) used for granting the permissions should have absolutely no effect on the code that verifies permissions before executing actions.
This sort of thing is not at all uncommon, although support for it has not been built into the .NET Framework. There are tools out there that can help with at least part of it (e.g.: AzMan), but I am unaware of any commercial framework on the .NET side of things that provides all the required pieces without requiring at least some custom coding. (There are some small open-source projects in this area, but you would need to evaluate their pros and cons within the context of your application(s).)