Home / ASP.NET Wiki / Security / Authentication and Authorization / Membership and Roles / Creating a custom membership provider

Creating a custom membership provider

 Rate It (2)

When working with an ASP.NET site that requires some sort of user authentication (almost every time, I'd say), we often need to establish our own logic, and use our own database instead of the one provided by ASP.NET (with our own data model or stuff).

There are basically two reasons why you'd want to create a custom membership provider class:

  • You wish to store your membership information in a database different from the one ASP.NET provides (which is an SQL Server Express database), like an Oracle or MySQL database or a Web Service.
  • You wish to store your membership information in an SQL Server database whose schema (data model) differs from the default one used by the System.Web.Security.SqlMembershipProvider class. An example of this would be if our company already has a shared membership SQL Server database for all applications. 

Given this, it's pretty likely you'll have to create your own membership class, and here's one way to do it:

First of all, implement a class that inherits from the abstract class System.Web.Security.MemershipProvider. This class, as well, inherits from another abstract class,  System.Configuration.Provider.ProviderBase, so we should implement those methods as well. Basically, what needs to be created is a class with the following definition:

public class MyProvider : MembershipProvider

After that, we need to initialize (implement) the class variables used by the base class, setting each one to the value required by our business logic:

//Minimun password length
private int minRequiredPasswordLength = 6;
//Minium non-alphanumeric char required
private int minRequiredNonAlphanumericCharacters = 0;
//Enable - disable password retrieval
private bool enablePasswordRetrieval = true;
//Enable - disable password reseting
private bool enablePasswordReset = false;
//Require security question and answer (this, for instance, is a functionality which not many people use)
private bool requiresQuestionAndAnswer = true;
//Application name
private string applicationName = "MYAPP";
//Max number of failed password attempts before the account is blocked, and time to reset that counter
private int maxInvalidPasswordAttempts = 3;
private int passwordAttemptWindow = 10;
//Require email to be unique
private bool requiresUniqueEmail = true;
//Password format
private MembershipPasswordFormat passwordFormat = new MembershipPasswordFormat();
//Regular expression the password should match (empty for none)
private string passwordStrengthRegularExpression = String.Empty;

Next, implement all the methods you need, with your own custom logic:

public override bool ValidateUser(string username, string password)
{
//For our example, user will be authenticated if username and password are the same
return username == password;
}

If by any chance you decide not to implement any of the base class methods (and not use the base logic, either), just throw a new NotImplemetedException:


public override string GetUserNameByEmail(string email)
{
throw new NotImplementedException();
}

The final step is to modify our Web.config file:

<configuration>
<system.web>
...
...
...
...
<membership defaultprovider="MyProvider">
<providers>
<add type="MyProvider" name="MyProvider">
</providers>
</membership>
</system.web>
</configuration>

This is obviously an alternative that requires time and work, but if well implemented, it's sure worth it.

Revision number 3, Wednesday, May 20, 2009 7:14:05 AM by hugonne

Comments

Need to mention thread safety: In general, ASP.NET goes to great lengths to prevent developers from having to write thread-safe code. HTTP handlers and HTTP modules, for example, are instanced on a per-request (per-thread) basis, so they don't have to be thread-safe unless they access shared state. Providers are an exception to the one-instance-per-thread rule. ASP.NET 2.0 providers are instanced one time during an application's lifetime and are shared among all requests. Because each request is processed on a different thread drawn from a thread pool that serves ASP.NET, providers can (and probably will be) accessed by two or more threads at the same time. This means providers must be thread-safe. Providers containing non-thread-safe code may seem to work at first (and may work just fine under light loads), but are likely to suffer spurious, hard-to-reproduce data-corruption errors when the load-and consequently, the number of concurrently executing request-processing threads-increases. The only provider method that doesn't have to be thread-safe is the Initialize method inherited from ProviderBase. ASP.NET ensures that Initialize is never executed on two or more threads concurrently. See this artical for more: http://msdn.microsoft.com/en-us/library/aa479030.aspx

If you privide little more details, then it will be very much helpful for me.

Related Articles

CreateUserWizard

Overview The CreateUserWizard control provides the user interface for the MembershipProvider object that communicates with the user account data store for your Web site to create new user accounts in the data store. The CreateUserWizard relies on the MembershipProvider

Forms Authentication

MSDN How To's How To: Create GenericPrincipal Objects with Forms Authentication - This How To shows you how to create and handle GenericPrincipal and FormsIdentity objects when using Forms authentication. How To: Protect Forms Authentication in ASP.NET

Shortcuts

Table of Contents

Top Wiki Contributors

(last 30 days)

  1. abiruban (1)