How to build a two-tier registration system


I have the requirement to build a website which allows users to register for an account. Registering will create a portal area for each registrant, with the username as part of the client portal. E.g., or perhaps by subdomain (so

From there, sub-users may register for an account. They visit the portal page of the main user, register and log-in.

The difficult part is that the same username needs to be able to be used under different main user portals. So ‘johnsmith’ can register for an account under one portal page, but a different ‘johnsmith’ can register with the same username under a different portal account.

Question is, how should this be architected? I’m looking to learn MVC - perhaps this kind of thing can be done easily with MVC? I’m assuming there’s no way to get this working with the standard .NET membership provider?

Thanks for any tips/advice on where to start here!

There are two topics here. One would be in regards to the entities, the other is in routing. I’ll address each.

I had a setup with an app I wrote a while back where a user registered an account and were supplied with a blog. Other users could ‘register’ to these blogs.

I solved this using a general entity structure like the below:


  • Id
  • Username
  • Password
  • Email
  • DisplayName (not unique)


  • Id
  • Title
  • AccountId


  • Id
  • DisplayName (not unique)
  • AccountId
  • BlogId

The issue of routing you described can be easily handled by mvc, however, there are issues…

  1. Searching by username defeats the purpose of the anonymous DisplayName.

  2. Multiple people may be using the same DisplayName, which rules out searching there as well.

I’d suggest two controller actions. …/Account/DisplayName and …/Membership/DisplayName then simply make the display names unique within their respective entities.

Hope that helps.

That’s a great start Serenarules, thanks. I’m totally new to MVC so forgive my questions, but from what you’re saying, there are essentially two registration tables: one for the ‘master’ account holders (who will create the portal) and one for the sub-account holders who will sign into the portal area of the master account holder? Did you create different membership providers for this, or is it possible to use standard ASP.NET membership for this?

In my case, I don’t want my master account holders to be able to use the same username, as their username will be part of their portal URL (so 2 users with the same username = two identical URLs = will not work). However, the sub-account holders will be allowed the same usernames, but not under the same master user.

Does this make sense, and is it doable without too much ‘hackery’?

Thanks very much, I really appreciate your advice here!

The account entity is main login point. The membership entity pairs an account with a blog.

I doubt the built-in membership system would handle this, though I didn’t even try. I wrote my own authentication system, which doesn’t use providers at all.

Note: You can derive your own implementations from the abstracts provided, but your system must still maintain pre-defined fields regardless of anything else you add.