2 Instances of SimpleMembership in MVC 4 Razor solutions

Question

I have a solution for a client I am working on that is being built in .net MVC 4 Razor that contains the following;

1. Public website with a client login area.
2. Private company webapp for running the company. This is not a website service area.
3. These are seperate apps. The company app will run as sub-domain.
4. They both run off the same SQL db.

The issue. I will end with seperate instances of the SimpleMembership, one for each app. However I will end with 2 sets of the webpages_ tables that get created with SimpleMembership for roles etc. From what I am aware of I cannot change the names of these tables. I can change the User table name without issues so I can users and adminusers. I have thought using my old homegrown login model as an alternative. Any suggestions or articles on doing what I want?

Answer 1

You are going to have to work around this, as you can't change the default webpages_ prefix, or (AFAIK) the database schema that the tables sit in.

The Simple Membership provider was designed to be highly customisable, but using it out of the box is going to save you a lot of work over rolling your own provider. Let's therefore assume the better option is to find a way to use it. The solution is either:

• two databases; or
• if you are stuck with a single database then could you use roles to separate your users.

The only small disadvantage in using roles is that you are then going to have to work a little harder on the UserProfile class. Typically you would put any extra user attributes on this class. If your two sites use different user attributes you will have to horizontally partition the tables, using something like Shared Primary Key Associations.

In my view this is actually going to be less work than maintaining two separate sets of Simple Membership tables in separate databases, or even in the same database. It's not so bad anyway, shared attributes like "LastLoginAt" can go into the UserProfile (and therefore you can develop a common library for both sites) and site specific attributes like "InternalExtensionNumber" can go into the partition table specific to your company users.

What's the downside? Well if someone gets access to the user roles table, they could assign a public user to get private site access. That said, if someone gets access to do that in the user roles table, you're probably already compromised and it can't get any worse.

Example:

If every user that registers with site 1 is given a role "PublicUser" and every user that registers with site 2 is given a role "AdminUser" then it wouldn't be hard to enforce a mandatory role within a given site, for example you could decorate every controller requiring authorization in the company app with:

[Authorize(Roles = "PrivateUser")]

Or you could enforce authorization across the entire site for the site role. To do this you can use AuthorizeAttribute and register the attribute as a site filter, and then use the AllowAnonymousAttribute to allow access to public methods:

// Add this to global.asax.cs to enforce authorization on all controllers.
public static void RegisterGlobalFilters(GlobalFilterCollection filters) 
{
  filters.Add(new HandleErrorAttribute());
  //  Add a setting to the web.config to specify the site role, 
  //  and then you can use the same value consistently when
  //  registering users and assigning them a role.
  string siteRole = System.Configuration.ConfigurationManager.AppSettings["SiteRole"];
  filters.Add(new System.Web.Mvc.AuthorizeAttribute() { Roles = siteRole });
}

If you wanted to go further than this you could extend the authorize attribute by creating your own and using it as appropriate at either site or controller level.