I'm going to add my vote for refactoring this code at some point to make use of a provider pattern.  I think we'll run into issues with this down the road as more and more people are using DotNetNuke to build social networking applications.  It's true that you could role your own role management, but it seems like such a waste and a source of potential confusion if you're building a commercial module to write a custom role infrastructure just because the built in role infrastructure won't let you assign more than 50 to 60 roles.  

Why would a user have this many roles?  Well, let's say that your using DNN as an infrastructure to build a social networking application where users can create groups and invite their friends to join these groups.  Because you'll be using these groups to limit access to resources, it's useful to make use of an infrastructure that already has all of the security mechanisms in place for granting or denying access.  

This is where this limitation concerns me and why I think it would be worth the effort to refactor this piece so that at a minimum it can be easily replaced by those who need to support an unlimited number of roles.  As we see more and more applications build where users can create groups on the fly and group related resources, such as third party modules, will need to be accessible to only members of this group, we'll need to see support in our platform grow to meet this demand.  In some applications, not only will users be given the ability to create groups, but users may want to limit access to third party modules in thier profiles to friend lists that they create.  These types of usage scenarios could easily result in users being a part of more than 50 groups.

Now, in terms of thinking of a solution to the problem, I realize that the level of effort may be high to refactor the code to use a provider model.  I wonder if there are other mechanisms that could be used to store more information on the client.  I noticed the other day when I set my location at weather.com that they asked me if it was OK to store my information in a more permanent way that could be recovered if cookies were lost.  Are they using the Flash SharedObject?  I haven't taken the time to find out.  Unlike cookies which have around a 4K limit, the Flash SharedObject infrastructure can be used to store up to 100k of data, giving us 25 times more storage.  If 50 roles were the limit for 4K, we could store 1250 roles using the Flash SharedObject.

Sebastian and Mitchel, I'm interested to hear your implementation thoughts regarding the social networking usage scenarios I've described.  I'm guessing from your comments that you would not recommend using the DNN role system.  If that's the case, then how do we create our applications so that third party modules can participate in the custom security infrastructure that we write?  How have others solved this problem?

 I agree that there shouldn't be a one-to-one mapping of users to resources through roles, but I'm stuck from a design perspective on how to create an infrastructure that allows:

• users to create groupings for access control like you can with Facebook friend lists
• users to create custom groups
• both of which will contain resources that require access control
• which also works with third party modules which depend on the built in DNN role infrastructure for access control

I can roll my own security infrastructure, but then I have to solve the problem of creating a scalable security infrastructure on my own when it seems that the DNN role infrastructure could be optimized for greater flexibility.  In addition, if I write my own security infrastructure, then I exclude the whole DNN module market.  This means my clients are stuck with only the modules which support my custom access control infrastructure, which are probably only the modules I've created.

I could easily see a user having a boatload of roles on my school's portal once it gets to the point where we want it to be. We're tied into the Active Directory so management-wise it's a moot point but for a typical student they belong to a program (Marketing, Management, Accounting, etc) so there's at least one group (or more if they're taking multiple streams at the same time); each course has an OU so they belong to that for each course they're taking; each course has sections that have a corresponding OU (which is a child of the course which is a child of the program). So if a student is taking 5 full time courses, a couple of coned courses in the evening they could be easily over 20 roles and with the AD at the college having very descriptive names on the OU it probably wouldn't take much for a cookie to reach the limit.

If my dean came to me and said, "Mike I want you to make a page for each program with a child page for each course and a child for each section and only allow users for the section to see it." I would probably have to implement all of the roles (right now I just check to see if they're a student or a staff member).