ASP.NET Form Security, Roles in a shared environment

Publishing to a shared hosting environment using ASP.NET requires a few changes to support form security and roles functionality please take a look at this link to see recommended changes to support this.



This article shows how to make role-based security work for a .NET 2.0 application on a shared hosting server using a remote SQL Server 2005 database.

Many have asked the question, My ASP application uses role-based security, and it works well on my "localhost" with SQL Server 2005 Express. How can I make it work on a production server in a shared hosting environment

Differences exist between implementation of a .NET role-based security web application in the development environment and the production environment. I decided to write this article after reading many complaints about newbies not understanding the implementation process. So a few points to be aware of when moving an application from the development machine to the production environment are mentioned here in the article.

Specific data providers and their respective code samples have their links posted in the Data Provider Implementation section and in the References section of this article.


Beginning with the Microsoft .NET 2.0 Framework, role-based access for ASP.NET web applications is controlled by the contents of two files:

  • The web.config file
  • The ASP.NET schema file

Once these two files are properly configured, Forms Authentication can then be used to create a secure web application.

When using Visual Web Developer (VWD) within its development environment, these two files are automatically configured for use on the localhost with the Cassini web server and a local user instance of SQL Server 2005 Express.

When deploying the application to the production environment, the default data provider must be changed from SQL Server 2005 Express. And the default ASP.NET schema file must be ported to a database file type for use within the web host’s production environment. Porting the ASP.NET schema file then requires that the web.config file be edited to use that file and its associated remote data server.

The web.config File

Among other uses, the web.config file is used to restrict access to directories (folders) of the ASP.NET web site. Within the VWD development environment, the ASP.NET Web Site Administration tool can be used to create access rules for the application’s web folders. This tool makes it easy to set up and configure a role-based security web application by automatically editing the web.config file to update all of the access rules for the application.

Also, web.config is used to declare which data provider to use for the ASP.NET schema file. The database type and connection string must be declared for the data provider.

When deploying the application to the production environment, the ASP.NET Web Site Administration tool cannot be used. And the web.config file must be manually edited with Visual Web Developer.

The ASP.NET Schema File

The ASP.NET schema file (Schema) is a database file, which contains the data schema, tables, views, and stored procedures, which are compatible for use with either the IIS or Cassini web server. Compatibility implies that the Schema must meet the specifications required by ASP.NET, such as†¦ The Schema has specifically named tables with pre-determined table definitions, along with methods to create and access the data.

The Schema is used to identify users, define personalization preferences, define user roles, and to declare membership of users within the defined user roles.

For SQL Server data providers, the Schema can be generated automatically by VWD with the ASP.NET Web Site Administration tool. Or, if the web host allows their use, other tools such as the ASP.NET SQL Server Registration Tool (Aspnet_regsql.exe) or the SQL Server Database Publishing Wizard can create the Schema.

For custom data providers, the developer must create a script to generate the Schema. Examples of such scripts are available from the links for custom providers that follow.

Issues with Data Deployment

By default, the Schema created within the VWD development environment is a Microsoft SQL Server 2005 Express database file, ASPNETDB.MDF, which is placed into the App_Data folder of the web application. The file is accessed by a local instance of SQL Server 2005 Express. The Cassini web server works well under this default scenario.

In a production environment, at least three reasons exist for not using the default Schema deployment scenario:

  • On the IIS web server, ASP.NET recognizes only one App_Data folder; the one located in the root directory of the web server. And access to the App_Data folder is usually not allowed, especially in a shared hosting environment. (Imagine hundreds of web sites trying to share a single Schema file. Although in some strange universe, it may be possible to have a set of users, roles, and membership access rules identical to each of the other hosted web sites on the server. But, that situation is improbable in the real world.)
  • SQL Server 2005 Express is not designed for production use and is not supported on production servers due to memory management issues.
  • In a production environment, a remote database is used and not a local user instance of SQL Server 2005 Express. Local, as in the database server is installed on the same machine as the web server. Remote, as in the database server is not installed on the same machine as the web server.

A Solution to the Data Deployment Issue

A simple solution is to have the web server use a remote database server. And on that remote database server, a uniquely named database Schema exists for each web site having role-based access. ASP.NET can then implement role-based access for each web site on the shared server, according to the access rules particular to any given web site.

Although SQL Server 2005 Express is not supported within a production environment, other data providers can be used for the Schema. Choose a data provider that is supported by the web host.

When changed from the default data provider, the Schema's data provider must be declared in the application’s web.config file; and the web.config file must then be saved. The application should be momentarily taken off-line, and then placed back on-line for the change in data provider to take effect.

Data Provider Implementation

Thanks to ODBC and OLEDB technologies, custom data providers can be created for practically any database accessible by the .NET web server. Data providers for the Schema may include:

Using the Code

While much material exists for implementing a solution to this question, few seem to completely cover the subject. Mainly, because the code samples only show segments of the editing necessary to set up the web.config file.

This code sample includes the entire script of the web.config file. This is the web.config file that worked for my web application. The specifc names have been changed, but the content is valid. Simply substitute your specifics for the generically-subsituted specifics in my code example.

The configuration is for a remote SQL Server 2005 database. For this example:

The remote data server:THEREMOTESERVERURL (For example,

The Schema file:THESCHEMA (A SQL Server 2005 data file, uploaded to the data server) (for example, wafflehut)

The Database Username: THEUSERNAME (for example, whodatis)

The Database Password: THEPASSWORD (for example, slaphappy)


Collapse |


<?xml version="1.0"?>
    Please refer to machine.config.comments for a description and
    the default values of each configuration section.
    For a full documentation of the schema please refer to
    "%22%22%22"""">" />
    LocalSqlServer" connectionString="Data Source=THEREMOTESERVERURL;Initial Catalog=THESCHEMA;User Id=THEUSERNAME;Password=THEPASSWORD;" />
    SqlProviderConnection" connectionString="Data Source=THEREMOTESERVERURL;Initial Catalog=THESCHEMA;User Id=THEUSERNAME;Password=THEPASSWORD;" />
    Forms" />
    c#" urlLinePragmas="true" debug="false" />
        AspNetSqlMembershipProvider" />
        LocalSqlServer" name="AspNetSqlMembershipProvider"
           enablePasswordRetrieval="false" enablePasswordReset="true"
            applicationName="/" requiresUniqueEmail="false" passwordFormat="Hashed"
            maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6"
            minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10"
            passwordStrengthRegularExpression="" requiresQuestionAndAnswer="true"
            type="System.Web.Security.SqlMembershipProvider, System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    true" >
        AspNetSqlRoleProvider" />
             System.Web, Version=, Culture=neutral,                               
             PublicKeyToken=b03f5f7f11d50a3a" />
    Off" />
  To improve performance, machine.config should contain only those
    settings that differ from their defaults.

NOTE: For purposes of clarity, the application's connection string and other configuration data are presented in plain text. Once the application is functional, be sure to secure the application's web.config file by taking industry-accepted security measures as outlined at the following link: DPAPI and Triple DES: A powerful combination to secure connection strings and other application settings


Within the Visual Web Developer IDE, the default deployment scenario works well for creating, testing, and debugging a web application. The ASP.NET Web Site Administration tool (WSA) automatically creates the proper web.config file settings for web folder access rules. WSA, also, creates and updates the default Schema file, ASPNETDB.MDF. However, this setup only works in the development environment.

Changes must be made when moving the final completed application to the production environment. Required changes include:

  • Creating a blank database on the remote database server. A username and password must be created for the web application to use when accessing the data. The web hosting provider can provide the details of how to access the remote database server to create the new database. The web hosting provider can also help with identifying the correct connectionString to use for accessing the new database.
  • Scripting the ASP.NET schema to the new database. The web hosting provider can assist with how best to do this step. Some providers allow the use of a tool, such as the ASP.NET SQL Server Registration Tool (Aspnet_regsql.exe). Other web hosting providers simply have the developer FTP the development datafile to a web folder, and then use a Restore function to populate the blank database file on the remote database server.
  • Uploading the application's directories and ASPX files to the production web server. But, do NOT upload the App_Data folder nor its contents.
  • Modifying the application's web.config file for the connectionString property for the Schema. It must point to the remote database server and the particular Schema data file for the application. Other connectionString properties must also be specified, such as authentication type (Forms Authentication), username and password.
  • Modifying the application's web.config file to update both the membership and roleManager providers. The default providers must each be first removed and then added. The remove step eliminates the default SQL Server 2005 Express provider. The add step must follow the remove step, and it adds the new data provider.
  • After the steps listed above are completed; rebuild, save, and test the web application. It should now function well with the role-based security features.
  • 1 Users Found This Useful
Was this answer helpful?

Related Articles

Are there any good ASP resources on the Internet?

Are there any good ASP resources on the Internet? One of the best ASP resources there is can be...

How do I enable ASP on my Domain / Website?

How do I enable ASP on my Domain / Website?   ASP is available depending on the...

How do I enable ASP.NET on my Domain / Website?

How do I enable ASP.NET on my Domain / Website?   ASP.NET versions 1 and 2 (3.5Sp1)...

Display detailed information rather than a generic 500 error

If you are receiving the dreaded 500 error, you can follow the below temporary patches to display...