You need to configure connection string and membership provider when you want to use SQL Server database or even your custom provider. In these cases, you have to modify web.config file directly or edit the configuration through the IIS MMC snap-in if you are running your application on IIS.
In case of using SQL Server storage (or other database-based storage), you have to configure the connection string as your first step and you can do this through the <connectionStrings /> section of the web.config file. For example, if you want to use a local database called MyDatabase where you have installed the database tables through the aspnet_regsql.exe tool as shown in the articles: How to create a data store as a step of Membership API in ASP.NET and How to use data scripts for ASP.NET services to modify membership database and database tables in ASP.NET you have to configure the connection string as follows:
<connectionStrings><add name=”MyMembershipConnString”connectionString=”data source=(local)\SQLEXPRESS; Integrated Security=SSPI; initial catalog=MyDatabase” /></connectionStrings>
Then, as your second step, you must configure the membership provider for the application. For this purpose, you have to add the <membership> section to your web.config file (if it’s not already there) below the <system.web> section, as follows:
<system.web><authentication mode=”Forms” /><membership defaultProvider=”MyMembershipProvider”><providers><add name=”MyMembershipProvider”connectionStringName=”MyMembershipConnString”applicationName=”MyMembership”enablePasswordRetrieval=”false”enablePasswordReset=”true”requiresQuestionAndAnswer=”true”requiresUniqueEmail=”true”passwordFormat=”Hashed”type=”System.Web.Security.SqlMembershipProvider” /></providers></membership></system.web>
Note: Provider configurations are always placed in the root web.config, as they affect the whole web application.
You can add multiple providers as child elements of the <providers> section, within <membership> section. Note: It’s important not to forget about the defaultProvider attribute on the <membership> element, because this attribute indicates the membership provider used by your application. Configured providers are shown in the ASP.NET web configuration when selecting the option Select a Different Provider for Each Feature in the provider configuration. This enables you selecting a separate provider for each feature as shown in the next picture:
The configured provider selected in the WAT
The next table describes the most important properties you can configure for the SqlMembershipProvider.
| Property | Description |
| name |
Specifies a name for the membership provider. You can choose any name you want. You can use this name later for referencing the provider when programmatically accessing the list of configured membership providers. Furthermore, the WAT will use this name to display the provider.
|
| applicationName |
String value of your choice that specifies the name of the application for which the membership provider manages users and their settings. This setting allows you to use one membership database for multiple applications. Users and roles are always associated with an application. If you do not specify an application name, a root application name called “/” will be used automatically.
|
| description | An optional description for the membership provider. |
| passwordFormat |
Gets or sets the format in which passwords will be stored in the underlying credential store. Valid options are:
– Clear for clear-text password storage
– Encrypted for encrypting passwords in the data store (uses the locally configured machine key for encryption)
– Hashed for hashing passwords stored in the underlying membership store.
|
minRequiredNonalphanumeric
Characters
|
Specifies the number of nonalphanumeric characters the password needs to have. This is an important part for the validation of the password and enables you to specify strength requirements for the passwords used by your users.
|
| minRequiredPasswordLength |
Allows you to specify the minimum length of passwords for users of your application. This is also an important property for specifying password strength properties.
|
| passwordStrengthRegular
Expression
|
If the previously mentioned properties are not sufficient for specifying password strength conditions, then you can use a regular expression for specifying the format of valid passwords. With this option you are completely flexible in terms of specifying password format criteria.
|
| enablePasswordReset |
The membership API contains functionality for resetting a user’s password and optionally sending an e-mail if an SMTP server is configured for the application.
|
| enablePasswordRetrieval |
When set to true, you can retrieve the password of a MembershipUser object by calling its GetPassword method. Of course, this works only if the password is not hashed.
|
| maxInvalidPasswordAttempts |
Specifies the number of invalid validation attempts before the user gets locked. The default value of this setting is 5. In many cases, you’ll likely want to set this to a lower level depending on your security policy.
|
| passwordAttemptWindow |
Here you can set the number of minutes in which a maximum number of invalid password or password question-answer attempts are allowed before the user is completely locked out from the application. In that case, the user gets locked out, so the administrator must activate the account again. The default value is 10 minutes. Depending on your security policies, you might want to lower or raise the value.
|
| requiresQuestionAndAnswer |
Specifies whether the password question with an answer is required for this application. This question can be used if the user has forgotten his password. With the answer he gets the possibility of retrieving an automatically generated, new password via e-mail.
|
| requiresUniqueEmail |
Specifies whether e-mail addresses must be unique for every user in the underlying membership store.
|
Important notes:
1. You can use one membership provider database for more than one application by leveraging property applicationName.
2. Every user, role, profile—actually, any object in the membership database—is connected to an application entry. If you don’t specify an applicationName property in the membership configuration, the API (and therefore any administration tool such as WAT) associates objects to the root application with the “/” name.
3. If you specify the applicationName property in the membership provider configuration, any object created by the membership API will be associated with an application specified with the name. Validation of credentials through the Login control or through the membership API works only against objects associated with the application configured in the applicationName property. That means if you configure your membership provider with the application name TestApp and you try to log in, the membership API (and therefore any controls sitting on top of it) will validate user names and passwords only against users associated with the application entry TestApp—even if users with the same name and password exist in the database, associated with other applications.