[Architecture] Roles for white-label service access.

Question

Okay,

I know I'm doing something wrong - but can't figure out a better way. I am developing a website which is going to allow users to setup their own mini-websites.

Something like Ning. Also, I have only 1 basic login and access to each mini website is provided (right now) via roles.

So the way I am doing this right now is:

Everytime a new mini website is created - say blah, I create 2 roles in my application. blah_users and blah_admin

The user creating the mini website is given the role - blah_admin and every other user wanting to join this mini website (or network) is given the role - blah_user.

Anyone can view data from any website. However to add data, one must be a member of that mini site (must have the blah_user role assigned)

The problem that I am facing is that by doing a role based system, I'm having to do loads of stuff manually. Asp.Net 2 controls which work on the User.IsAunthenticated property are basically useless to me now because along with the IsAuthenticated property, I must also check if the user has the proper role.

I'm guessing there is a better way to architect the system but I am not sure how. Any ideas?

This website is being developed in ASP.Net 2 on IIS 6. Thanks a tonne!

Answer 1

I afraid standard roles-related stuff of ASP.NET is not what you need. You can try to change authentication module so it will:

1. Log you in with cookie.
2. Determine what roles does your visitor have. Perhaps you will use some special table that corresponds user and site.
3. Make custom principal with user roles enumerated and assign Identity and Principal to the current request.

I also don't think that making special roles for each site is good idea. When you would have hundred sites, you would also have two hundred roles. Pretty unmanageable, I afraid.

When we were solving similar task, we were just not using standard controls. We had single set of roles used on all sites. Membership of concrete user is determined according to current site and his relations to this site.

Addition: Another possibility to investigate is Application that exists in ASP.NET authentication system. Maybe it's possible to isolate each subsite into separate application?

Update: Method that works for our application.

1. Do not make a lot of cloned roles. Use only two: users and admin. If your sites are public then "users" role could be just global - user on one site doesn't differ from user on another site. If "users" and "everyone" are different roles, then of course "users" should also be bound to a site.

2. Use standard ASP.NET Membership users, but do not use standard role mechanism.

3. Make a mechanism for storing relation between site and user. It could be simple table that holds site id, user is and role.

4. What you have to override is IsInRole method. (Method**s** to be exact, i'll cover it later). This method is in IPrinciple interface, so you have to make your own principal object. It's quite simple.

   1. Method IsInRole of this type should look take current site (from HttpRequest) look into the site-user table and get roles

5. Then you have to associate your principal with a request. Do it in PostAuthenticateRequest event.

6. There is also RoleProvider. Honestly I'm not sure when is it used, but it also have IsInRole method. We can override it in the same way. But other methods of this provider are harder. For example AddUsersToRoles. It accepts array of user names and roles, but to what context (site) should it be added? To current? Not sure, because I don't know when this method is called. So it requires some experiments. I see (Reflector helps) that RopePrincipal by itself uses RoleProvider to fetch list of roles, so maybe it's implement only RoleProvider, using standard principal. For our application this is not a case, so I can't say what problems could be hidden here.