Building on the Basics

Customizing Membership and Role Services

asp:Feature

LANGUAGES: C#

ASP.NET VERSIONS: 2.0

 

Building on the Basics

Customizing Membership and Role Services

 

By Chris D Agostino

 

There are several application services that are incorporated into the ASP.NET 2.0 Framework. Two of these application services are the Membership and Role APIs, which allow a developer to quickly and easily incorporate authentication and authorization into a Web application. Typically, these services are preconfigured to use a dedicated database to store membership and role information. If you already have a database for your Web application, this physical separation of data can have some drawbacks. In this article I will point out some disadvantages to storing the membership and role information in a separate database and explain how you can configure your application s database and set up the Membership and Role services so that all the data is stored in a single database.

 

The Situation

With a typical Visual Studio 2005 installation, the Membership and Role services are configured to use a dedicated SQL 2005 Express database, named ASPNETDB, as their data store. This database is normally stored in the application s App_Data directory. When I first integrated these application services into one of my Web applications I found that storing the membership and role information separate from the rest of the application s data created an unnecessary duplication in data and programming. Even though the Membership and Role APIs provided a way to create users, manage accounts, and maintain role information, I still had to develop my own interface and create the necessary database objects for storing similar information in the application s database. I needed this information so I could store user preferences and e-mail addresses, and give users and roles access permissions to various objects stored both inside and outside the database (such objects included documents and files).

 

I wanted to come up with a solution that would allow me to combine the two databases so that I could take advantage of the interfaces already developed for the services, and to also integrate their required data structure into my own application database so I could eliminate the duplication of data and programming required. After doing some research I was relieved to find that I could easily configure the Membership and Role services to use the existing application database for their data store and eliminate the need for the ASPNETDB database and accomplish the additional goals listed above. Let s look at how this is accomplished.

 

Configuring Your Database

I ll assume you already have an ASP.NET 2.0 Web application that uses a SQL 7.0 or later database that needs to be configured. The first thing we need to do is incorporate the membership and role data structure into your existing database. There are three SQL scripts installed as part of the Visual Studio 2005 install that need to be run against your database: InstallCommon.sql, InstallMembership.sql, and InstallRoles.sql. Located in the %SystemRoot%\ Microsoft.NET\Framework\v2.0.50727\ directory, these scripts will create all the tables, stored procedures, and views needed for the Membership and Role services.

 

Execute each script in the order listed above; however, prior to execution you ll need to replace the default database name ASPNETDB with the name of your database. Each script contains two instances of the name to be replaced. Once the scripts have been executed, grant the user account used to access the database from the Web application Execute permissions on all the new stored procedures and Select permission on the views that were created. The new stored procedures are prefaced with aspnet_ ; the views are prefaced with vw_aspnet_ .

 

Figure 1 contains a diagram of the pertinent tables created by the scripts. The aspnet_Applications table is used to identify each Web application the database will service, because it s possible to incorporate more than one Web application into this database. Each Web application is identified by a uniqueidentifier named ApplicationId. The aspnet_Users and aspnet_Membership tables are used to identify each Web site user for each application and contain various user information, such as the username, password, e-mail, and login information. Each user is identified by a uniqueidentifier named UserId. If you wanted to extend this model and store additional user information, such as first name, last name, and middle initial, you could simply create an additional table with the required columns using the UserId column as the primary key. The other two tables shown in Figure 1, aspnet_Roles and aspnet_UsersInRoles, are used to store role information and identify which users belong in which role(s). If you assign permissions in your database, you can now use the RoleId and UserId already created for you to identify the appropriate users and roles.

 


Figure 1: Database diagram of the tables required by the Membership and Role application services.

 

When extending this data model by using the columns provided, you may need to modify one or more of the stored procedures created by the scripts or create triggers so that you appropriately account for the use of the data in other tables. For instance, if you use the UserId in other tables throughout your database, you may need to modify the aspnet_Users_DeleteUsers stored procedure or create a trigger so that you delete all the necessary data associated with a particular user and you don t leave any orphaned records. It is also recommended that you create the appropriate constraint(s) on the associated columns.

 

Configuring the Web Application

The next task we have to do is configure the Web application. By default, the Membership and Role services utilize a connection string named LocalSqlServer. The connection string information is stored within the Web server s machine.config file and is normally configured to point to the default SQL Express database created for each Web application. This connection string information needs to be overridden in the application s web.config file. To do this, we ll need to create a new section named within the section of the web.config file:

 

 

 

  "Data Source=localhost; Initial Catalog=myapplicationdb;

  UID=webuser;Password=password" />

 

The above example creates the section inside the portion of the web.config file, removes the LocalSqlServer connection string created in the machine.config file from the application s connection string settings, and creates a new connection string named LocalSqlServer that points to the database we previously modified.

 

The section is new to ASP.NET 2.0 and provides a common repository for developers to store an application s connection string information. A developer can also now encrypt sections of the web.config file to further secure sensitive information, such as connection strings.

 

We are now ready for the final step: running the ASP.NET Configuration utility. This utility performs many functions that help developers quickly and easily configure their Web applications, some of which include: setting an application s authentication mode; creating and managing users; creating and managing roles; and assigning users to roles. The ASP.NET Configuration utility can be accessed from within Visual Studio 2005 by selecting Website | ASP.NET Configuration, as shown in Figure 2.

 


Figure 2: Launch the ASP.NET Configuration utility.

 

Once you select the ASP.NET Configuration menu option, a new browser window should open and present you with a screen similar to the one shown in Figure 3.

 


Figure 3: The ASP.NET Configuration utility home page.

 

Next, select the Security tab located at the top of the page. From the Security page (shown in Figure 4), one can set the application s authentication type, manage users and roles, and create access rights to particular directories. To enable Forms authentication, click the Select authentication type link available under the Users section (as shown in Figure 4). From there you ll be asked how users are going to access your site. If you choose From the Internet, it will configure your web.config file to use Forms authentication. Conversely, if you choose From a local Network, it will configure your web.config file to use Windows authentication. Because we want to use Forms authentication, select From the Internet and press the Done button. On the subsequent page select the Enable roles link located within the Roles section of the Web page, as shown in Figure 4.

 


Figure 4: Select the Enable roles link to enable Roles. You can also use the Configuration utility to create users, manage users, create access rules, and assign users to roles.

 

Your application is now configured to use the Membership and Role application services, and any data created through the use of these services will be stored in your application s database. Additionally, you can now use the ASP.NET Configuration utility to manage users and roles, assign users to roles, and secure the appropriate directories within your application.

 

Conclusion

ASP.NET 2.0 application services such as the Membership and Role services are commonly referred to as building blocks. This is because they provide the framework for common programming tasks used throughout the Web development community. These building blocks can greatly increase developer productivity and save precious time. They are called building blocks because they sometimes do not in and of themselves provide an entire solution, and may need to be extended to meet your needs or they may need to be modified to fit into an existing framework. In this article I have shown you how to set up and configure the Membership and Role services in such a way that they can be incorporated into your application s database and expanded, if necessary.

 

Chris D Agostino is an MCAD and owner of CJD Consulting, a company located in Portland, OR that focuses on Web and application development. Chris has been developing Web applications for the last seven years. Find out more about him at http://cjdconsulting.com or e-mail him at mailto:[email protected].

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish