Extending ASP.NET role providers

Question

Because the RoleProvider interface seems to treat roles as nothing more than simple strings, I'm wondering if there is any non-hacky way to apply an optional value for a role on a per-user basis.

Our current login management system implements roles as key-value pairs, where the value part is optional and usually used to clarify or limit the permissions granted by a role.

For example, a role 'editor' might contain a user 'barry', but for 'barry' it will have an optional value 'raptors', which the system would interpret to mean that Barry can only edit articles filed under the 'raptors' category.

I have seen elsewhere a suggestion to simply create additional delimited roles, such as 'editor.raptors' or somesuch. That's not really going to be ideal because it would bloat the number of roles greatly, and I can tell it's going to be a very hard sell to replace our current implementation (which is also very less than ideal, but has the advantage of being custom made to work with our user database).

I can tell already that the concatenation method mentioned above is going to involve a lot of tedious string-splitting and partial matching.

Is there a better way?

EDIT: My initial goal was to use more built-in ASP.NET functionality. For instance, control access via <authorization/> elements in the Web.config. Doing this, as far as I can see, requires implementing roles themselves. Our current system's concept of auths seemed to fit very well apart from that one limitation.

Answering mnemosyn's questions

1. Yes. We have a central database for users, applications and their authorisations. It's a core system and there's no going around it.
2. Currently our system is not hierarchical, and it actually takes quite a lot of effort to maintain. When an application is created, a set of authorisations are defined (e.g., 'admin', 'user', 'poweruser', 'gatekeeper', 'keymaster', etc.). Users are then associated with those authorisations with the optional value for a unique combination of user and (app-specific) authorisation.
3. Can you elaborate on these 'categories' of which you speak?

Answer 1

This really sounds like an architectural issue to me.

First, you need to determine what you need, exactly. In a second step, map this to a concrete implementation. To jump ahead on that one: I wouldn't use the built-in providers for anything but the most simplistic cases. Also, this problem quickly gets very complicated, so I'd try to keep it as simple as possible.

To elaborate your needs, try to determine:

• Do you really need to map the role concept to the database, as you would in a CMS? Or do changes to your role system imply a modification to the system. In that case, you could go for a much simpler solution and put an enum into the user. This will save a lot of database accesses, makes joins simple selects, etc.
• What are you trying to achieve through the multi-role concept you explained? Is it really roles that you need? How about individual permissions? Do you, for instance, have a hierarchical structure so that every node can have a certain set of permissions associated with it, much like windows' file security concept?
• If it's only categories, why not map categories to users, i.e. give each user a certain role in each category. This will require some tweaks for default category, etc.

A few tips there: Don't go for whitelists, always use blacklists. Controlling whitelists is a pain, esp. when a lot of rules come together. In drupal, for example, I think this is one of the major flaws (which is why they're rebuilding it to use blacklists in version 7). Allowing a user to do something they shouldn't is usually a much bigger issue than the other way around.

The windows file access concept is very complicated, because it has both black- and whitelisting, which additionally can be inherited - so try to keep your solution much simpler than that.

The string concatenation thingie sounds rather dangerous to me, I'd go for a cleaner solution in any case. This type of meta-logic gives headache.