Membership, MembershipProvider and MembershipUser relations in ASP.NET?

Question

I store user data in a MSSQL table called Users. What I want to is to have accessible all user's data for actually logged user (email, address, phone, if the user is subscriber etc.).

I don't want to use profiles so I decided to use custom MembershipProvider (or do you know some better, less painful way?).

What I don't understand is MembershipUser and Membership. If I inherite from MembershipProvider, in overriden methods I control access data from and to database.

But how do I use inherited class from MembershipProvider? If I want to authenticate user by using membership, I should do:

if(Membership.ValidateUser(string username, string password))
{
   FormsAuthentication.RedirectFromLoginPage(string username, string password);
}

But where is class inherited from MembershipProvider? And when to use a class inherited from MembershipUser? And what is relation between Membership and MembershipProvider?

Answer 1

While it's not crystal clear on MSDN, it's not all that complicated. There's a trio of classes:

• Membership: provides utility methods and a point of entry -- basically a Singleton (static class).
• MembershipProvider: acts as a data accessor and factory for MembershipUser objects.
• MembershipUser: represents an individual user.

A custom MembershipProvider is selected (by code in Membership) based on your application's configuration: configuration/system.web/membership. Here's where you bring your provider into play. Your MembershipProvider implementation must be written to access whatever data store you prefer for users: your User table in this case.

MembershipUser objects are only created through your MembershipProvider. The MembershipProvider.ValidateUser() method should check against your data store that the user/password combination is valid. The MembershipProvider.GetUser() retrieves user information -- use it within an access protected page and pass in System.Web.HttpContext.Current.User.Identity.Name as the current authenticated user.

This said, I hope you are sure you don't want to use Profiles, and really want to have a separate User table. If you are writing an internal application, using an existing Active Directory or LDAP-enabled data store would reduce administration costs and probably security risks. There are hundreds of things you can easily do wrong when going the MembershipProvider route. Do you use salted hashes? How are you protecting the User table against manipulation? MSDN covers only a fraction of the security issues you may face.

Answer 2

The specific provider used is controlled on the web.config. You can actually set more than 1 provider, and have a default one. Check: http://msdn.microsoft.com/en-us/library/6e9y4s5t.aspx.

When called like that, membership just uses the default provider. You would inherit MembershipUser, if you wanted to provide extra info for the user, but that will tie the rest of your code to your specific provider.