Using IIS for ASP.NET member/role management (1): Security and Configuration Overview

asp.net|iis| Security

　　Apply to:

Microsoft asp.net 2.0
Microsoft Visual Studio 2005
Microsoft Internet Information Services

Summary: Peter Kellner wrote two articles on creating an application to manage the Microsoft asp.net 2.0 membership database, this is the first. This article focuses on how to ensure the security of the solution to ensure that only appropriate administrators can access the data.

　　Summary

This series consists of two articles on how to safely use and set up a three-tier solution for managing ASP.net membership and Roles, this is the first article. This article will discuss how to configure, use, and, most importantly, secure this solution and outline how to implement it in a typical Microsoft asp.net 2.0 Web solution. Membership and Roles objects are considered to be operational without having to delve into their internal structure. Managing members and Roles seems to be the same as managing data in a simple data source. In the second article, the internal structure of these controls and objects is described in detail so that developers can create their own controls and objects using similar techniques.

　　Brief introduction

ASP.net 2.0 extends user authentication directly into the domain of application programming. With a standard. NET Library Reference (system.web.security), developers can create full authentication for their applications with only a few extra work. Keep in mind that the necessary actions must be performed to ensure the security of the application that you create as much as possible during use.

This article outlines security mechanisms and displays sample security settings, which are essential elements of creating a secure environment for WEB applications. ASP.net 2.0 provides a number of different configuration options, and whether these options are necessary depends on the security requirements. This article describes the pros and cons of these configuration options.

　　Security Considerations

Ensure the security of the physical environment

It is often said that the security of the computer is determined by the power switch on the front panel of the computer. Physical protection is fundamental, regardless of how closely the OS level protects the system. Therefore, it must be assumed that any user who has access to the computer physically will always be able to compromise the integrity of the computer in some way.

Secure the domain environment

You must follow best practices for setting up user accounts, passwords, and permissions. For example, if a user without appropriate permissions can access a database that contains the security data used by the WEB application, the application can be compromised.

Ensure the security of the. NET Environment

The. NET environment allows you to set code access security. This means that individual systems and application libraries can be associated with different levels of trust. This is important in some environments, such as a shared hosting environment in which multiple WEB applications can run. Each WEB application that may be owned by different users may require isolation and protection from each other. In addition, if this isolation is not done, each WEB application can affect critical system functionality.

This article assumes that the ASP.net user (IIS is running on behalf of the user) runs at the highest level of trust. This is like a WEB application running in a specialized environment.

asp.net relationship to IIS

When working with IIS, ASP.net supports three authentication providers: Forms Authentication (using application-specific logic), Passport authentication (a centralized authentication service provided by Microsoft), and Windows authentication (using Direct Authentication provided by IIS). This article uses the default authentication for the ASP.net project: Forms authentication. The authentication mode is specified in the Web.config file. The syntax is selected as follows.

<authentication mode = "{windows| forms| Passport| None} ">
</authentication>

The flowchart describes the process to follow when a user logs on from a WEB client.

Keep in mind that this article was written in 2001, when the process was appropriate for IIS 5.1, not the current IIS 6.0 or later.

Figure 1:iis and asp.net security process

　　role-based Security in the ASP.net 2.0 Web site

Initial installation and configuration

Web.config files/infrequently changed items

Some parameters that affect the overall operation of ASP.net 2.0 Web applications are set in the Web.config file. The sample parameters include references to the membership provider (or database), the required password strength, and whether to register e-mail messages. The relevant sections of the Web.config file are shown below, which contains examples of minimum security configuration values. Details can be obtained by accessing Visual Studio 2005 Help and then reviewing the membership members. Each security parameter is described in detail here.

<providers>
<remove name= "AspNetSqlMembershipProvider"/>
<add name= "AspNetSqlMembershipProvider"
Type= "System.Web.Security.SqlMembershipProvider,
System.Web, version=2.0.0.0, Culture=neutral,
PUBLICKEYTOKEN=B03F5F7F11D50A3A "
Connectionstringname= "LocalSqlServer"
Enablepasswordretrieval= "false"
Enablepasswordreset= "true"
Requiresquestionandanswer= "true"
Applicationname= "/"
Requiresuniqueemail= "false"
Minrequiredpasswordlength= "1"
minrequirednonalphanumericcharacters= "0"
Passwordformat= "Hashed"
Maxinvalidpasswordattempts= "5"
passwordattemptwindow= "10"
Passwordstrengthregularexpression= ""
Commenttimeout= ""/>
</providers>

In addition to the Web.config file section shown above, the Machine.config file contains the default connection string for the database associated with membership. You can configure a different connection string in the Web.config file. To add additional security, you can encode the connection string and encrypt the membership database password. Many articles have dealt with these eclectic approaches. A good example of how to use encryption in a Web.config file is provided in Microsoft's Quick Start Guide (English).

web.config file/.aspx page security

You can specify a security level for each Web page in your Web application. You can do this by specifying the roles you need to access the page. The syntax in the Web.config file is very simple. For example, the following web.config fragment specifies that only users who have a role designated as Administrator can access the Web page membershipgrid.aspx.

<system.web>
<location path= "Membershipgrid.aspx" >
<system.web>
<authorization >
<allow roles= "Administrators"/>
</authorization>
</system.web>
</location>
</system.web>

For example, to specify that only a specific role can access all pages in a subdirectory, the Web.config file is as follows. In this example, only users who are assigned to the role of the Administrator can access all files in the ~/admindir path.

<system.web>
<location path= "Admindir" >
<system.web>
<authorization >
<allow roles= "Administrators"/>
</authorization>
</system.web>
</location>
</system.web>

Web.config file/Internal. aspx page security

Many times, you need to provide more precise security than the above. That is, you might want to provide protection for a control, such as a button, or an ASPX page. To do this, you need to programmatically change the properties associated with the affected control of the session. For example, if you need to hide a Delete button based on a user role, you need to perform two steps: First, you should add a method named ShowButtonBasedOnRole to the Codebehind class of the Web page. Returns trueif the user has the required role, falseif the user does not have the required role.

protected bool ShowButtonBasedOnRole (string roleofinterest)
{
Return User.IsInRole (roleofinterest);
}

Then, on the actual ASPX page, based on the embedded code method ShowButtonBasedOnRoleTo set the visibility property of the button. The actual declaration of the button is roughly as follows.

<asp:button id= "Button1" runat= "Server" text= "button" visible= ' <%# (bool) showdeleterowbasedonrole ("Administrator" )%> ' >/>

If the button is based on any of the roles that are set, the incoming parameter can be changed to a string, and all of these roles are checked before returning the answer that the user is assigned to one of the roles.

Using the member/Role Manager aspx page

To use the ASPX pages (membership.aspx) included in this entry, you need to perform the following steps. First, you need to copy the two data classes in the article project file and include them in the App_Code directory of the target project. These two files are MembershipDataObject.cs and RoleDataObject.cs. You then need to move the ASPX file membership.aspx and its containing code page Membership.aspx.cs to the current project.

Be sure to provide protection against this page to prevent any users who are not designated as Administrator roles from accessing it. Otherwise, any user can modify the logon information of other users. To do this, make sure that the Membership.aspx page is protected in the Web.config file. The web.config file is used for this purpose in the following example.

<system.web>
<location path= "Membership.aspx" >
<system.web>
<authorization >
<allow roles= "Administrators"/>
</authorization>
</system.web>
</location>
</system.web>

Because this page is protected, the currently logged-on user account must be designated as the Administrator role to access this page.

The best way to do this is to execute the following code once, and then remove the code from the WEB server. For example, you can perform in the page load event of a asp.net Web page. Then, after calling this page, remove it from the server. This allows you to access the membership Management page only by using the password login account admin.

Roles.createrole ("Administrator");
Roles.createrole ("User");
Roles.createrole ("Guest");
Membership.CreateUser ("admin", "Enter strong password Here");
Roles.addusertorole ("admin", "Administrator");

　　Conclusion

When setting up any Web site, be sure to verify that users will be using the site and understand their related security requirements. For example, configuring simple security is sufficient if the site is to be used by the company's internal groups, without external user access and with no sensitive data. That is, there is no need for encryption, loose password constraints, and so on. Authentication can be a convenient way to track the identity of the user who enters data. Conversely, if your Web site is on the Internet and handles confidential data, be sure to lock the site as much as possible, allowing only authenticated users to access it.

This article briefly describes the issues that need to be noted when setting the security of a ASP.net web site, and explains how to add a secure page to modify the membership and role information of the users who log on to the site. This series is made up of two articles, and the next article assumes that the reader is aware of the security implications of developing the site and will detail how the Membership Management page works.

Author Introduction

Peter Kellner, who founded 73rd Street Associates in 1990, has successfully provided more than 500 clients nationwide with a system for the management of university clinics, insurance companies and a one-stop doctor's clinic. Ten years later (2000), a large insurer bought 73rd Street Associates, and Peter began his new career as an independent software consultant. Currently, he covers ASP.net, Oracle, Java, and VOiP, and will soon include SQL Server. When he was not working, Peter spent most of his free time on a cycling trip. He has traveled all over the world by bike. Recently, he and his wife, Tammy, took only 27 days to complete a ride from the California State to Georgia.

His blog site is http://peterkellner.net/. You can find this article and the code listed in the download area.