ASP.NET MVC3 / User registration, membership, roles and privilege

Question

In my application I need to register users. The users can be any of three: admin, client and general. They have different attributes (Admin may have only name, client may have company address and so on). The default MVC membership scheme is okay but how can it be extended to register more information during registration time? Or should I use custom membership?

I need to have a record of clients and general users with clientID or generalID.

Answer 1

The default MVC membership scheme is okay but how can it be extended to register more information during registration time? Or should I use custom membership?

I think too many people, yourself included, are expecting to get too much from the default ASP.NET Membership Provider. It was never designed to handle application-specific things, like what company your customer works for, your admin's name, and so on. It's main purpose is storing passwords for authentication.

Sure, the password needs to be linked to a username, so that there can be a 2-key authentication pair. Sometimes you also need the user's email address, when it is different from their username, in order to contact the user regarding their password. But don't store anything else about your users in the membership store. Store it in your application database.

In order to join data between your application and the membership provider, use the membership provider's UserName or ProviderKey as a column in one of your database tables. You end up with 2 entities which are not explicitly related. You can even have your SqlMembershipProvider implemented in a separate database from your application database. Even if they are in the same database, avoid having a foreign key between any of the provider tables and your application tables. This muddies the waters between what you own, and what you "outsource" to the membership provider.

You end up with 2 physically isolated representations of your user. One is the MembershipProvider, which contains a password for your user. The other is your application, which contains other business-specific details. The two are only logically associated within your application. After you authenticate a user with the membership API, their UserName and/pr ProviderKey become available to your application. You can then use that piece of data to query your app database and get the additional details. This is where you might put something like the clientID or generalID you mentioned.

If you look at the System.Web.Security.Member* API, this should make things clearer. It does one thing really well -- associating your users with passwords and other information related to password resetting (like the email address, question and answer, etc). So outsource just the password provider, and rely on your application to do the important stuff.

Answer 2

I highly suggest creating your own membership roles. It's dead simple and nothing can beat the flexibility of having your own implementation.

Here's a video I made a while back showing you step by step how to achieve this:

http://www.youtube.com/watch?v=BsxUsyMSGeA

The gist of it is, you create your own AuthorizeAttribute and create your own roles; protecting each controller or even individual Action methods along the way.

The one drawback of this approach is that you can determine what Role a user has in your system, but not what a Role can do in your system. Does that make sense?

There are other choices if you need to edit what a role can do at runtime.

Answer 3

You could customise the default profile provider or create your own... Follow this reference http://msdn.microsoft.com/en-us/library/8zs47k7y

You can add new properties to the profile for anything in the web.config too