ASP.NET 2.0 supports a provider-based model for a number of application services including membership. The membership provider is therefore a component that defines the contract between ASP.NET applications and the repository of membership information. Among other things, the contract includes methods to validate users' credentials; change and reset passwords; and create, find, and delete user accounts.
There are two main places where membership information can be held — a database and Active Directory. Accordingly, ASP.NET comes with two main membership providers, one for database and one for Active Directory.
The SqlMembershipProvider provider reads and writes membership information in made-to-measure tables in the aspnetdb.mdf database in SQL Server 2005 Express. You create the SQL Server database by running the aspnet_regsql.exe utility from the command line. Alternatively, you can do the same from within the Web Site Administration Tool available from the Website menu in Microsoft Visual Studio 2005. By simply changing the connection string in the site root web.config file, you can make the membership information flow into a SQL Server 2000 or SQL Server 2005 database as well, as long as the database internal layout is not modified.
The ActiveDirectoryMembershipProvider provider manages storage of membership information in Active Directory and Active Directory Application Mode (ADAM) user stores. When using the Active Directory provider, you specify the connection string in the web.config file along with valid credentials to access the Active Directory server. If you do not specify account credentials, Active Directory will use the credentials of the ASP.NET worker process.
It is important that any security measures set at the Active Directory provider level are verified against the settings in the Active Directory environment. You could, for example, configure your Active Directory provider to accept six-character long passwords. However, if the password doesn't meet Active Directory requirements — a minimum of seven characters for a password — the operation fails. As a result, the strongest security policy is always applied.
The Active Directory provider also supports account lockout as part of the contract. Basically, it tracks the number of failed password attempts (and failed password answer attempts) in the specified period and locks out a user when too many attempts are made. By default, users are not allowed to try it more than five times in ten minutes. However, it is important to know that any account locked out by the Active Directory provider doesn't appear as locked out in the Active Directory environment. The account lockout simply prevents the user from accessing any ASP.NET application protected by the Active Directory-powered membership system. The user will still be able to log on to Windows using her Active Directory account.
You can use ActiveDirectoryMembershipProvider also in an Active Directory scenario where multiple domains are defined. Suppose you have two domains, each with a connection string entry in <connectionStrings> pointing to the specific user database. You define an instance of the Active Directory provider for each domain to support. Each entry will have different settings for its connection string and perhaps administrative account.
<providers>
<add name="TestDomain1"
type="System.Web.Security.ActiveDirectoryMembershipProvider, ..."
connectionStringName="TestDomain1ConnString"
connectionUsername="TestDomain1\Admin"
connectionPassword="..." />
<add name="TestDomain2"
type="System.Web.Security.ActiveDirectoryMembershipProvider, ..."
connectionStringName="TestDomain2ConnString"
connectionUsername="TestDomain2\Admin"
connectionPassword="..." />
</providers>
The user must indicate the domain in the login page along with credentials. Once you know the user's domain, you change the validation code of the login page as follows:
MembershipProvider domainProvider;
if (domainName == "TestDomain1")
domainProvider = Membership.Providers["TestDomain1"];
else if (domainName == "TestDomain2.test.com")
domainProvider = Membership.Providers["TestDomain2"];
if (domainProvider.ValidateUser(userName, pswd)
{
:
}
In general, the two predefined membership providers serve the vast majority of the cases. However, a custom membership system is reasonable if you want to use a non-Active Directory Lightweight Directory Access Protocol (LDAP) provider for authentication, a local or remote Web service, or in general, a completely custom validation algorithm.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Network and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and Applied XML Programming for .NET. Contact Dino at [email protected].
