ASP.NET Security


This section talks about adding security to your Web applications by taking advantage of the mechanisms that ASP.NET provides. The three types that are currently implemented are forms (sometimes referred to as cookie authentication), Windows (which we have already covered in our discussion of NTLM and Kerberos), file and URL authorization, and passport .

Forms Authentication

Forms authentication , sometimes referred to as cookie authentication, is used to authenticate requests to HTML content based on credentials a user provides. For example, a user might be able to access a Web site, but access to a " Members Only" link might be restricted unless the proper credentials are given. The credentials usually are a username and password that are typed in and validated against a known list of valid users.

For forms authentication, a login URL is specified in the Web.Config file. Then, when users try to access restricted content, they are automatically redirected to the login page. From the login page they can enter the proper credentials, and then be allowed access if the credentials match up to information in some sort of list (which is usually contained in a database). The process is shown in Figure 18.1.

Figure 18.1. This is the process for forms authentication that lets only authorized users access special content.


Implementing Forms Authentication

The first thing you must do before implementing forms authentication is edit the Web.Config file. In the authorization section, specify who will be denied access, and optimally who will be granted access. To deny anonymous users, use the ? character as follows :

 <authorization>    <deny users="?" />  </authorization> 

To deny all users, use the * character as follows:

 <authorization>    <deny users="*" />  </authorization> 

You can grant some users while denying others, as the following example shows:

 <authorization>    <deny users="Jim, Mary, George" />    <allow users="Rick, Kathy, Steve" />  </authorization> 

You also must specify in the Web.Config file what type of authentication mode you want to use. There are four types: None, Forms, Windows, and Passport. (I will spend more time discussing authorization and authentication Web.Config entries in the section titled "URL Authentication.") The following example shows how to deny access to anonymous users and set the authentication mode to Forms:

 <authorization>    <deny users="?" />  </authorization>  <authentication mode="Forms">    <forms name=".FIRSTFORMDEMO" loginUrl="login.aspx" protection="All"      timeout="30" path="/">  </forms>  </authentication> 
Creating a Sample Application with Forms Authentication

Creating an application that enables users to log in and be authenticated couldn't be easier. I've created a simple demo application that does just that. And I added the code from the preceding section to the Web.Config file so that anonymous users must log in, the Web application uses Forms authentication, the login URL is login.aspx , and the timeout before the login expires if there is no activity is 30 minutes.

I then created two Web forms. One is WebForm1.aspx and the other is login.aspx . WebForm1.aspx represents the content that users are seeking (although in this case there isn't much to see because this is a simple demo application). Login.aspx is the login page to which users are redirected if they have not already been authenticated. You can see the login.aspx page in Figure 18.2.

Figure 18.2. This page asks users to enter name and password.


The login.aspx page has some code behind it that attempts the authentication. It is fired off after a Button event happens. First, the name and password form fields are retrieved and made uppercase. (You might not want to make them uppercase in many cases.) The name and password data (contained in the strName and strPassword variables ) is then checked against four allowable name and password combinations. If a correct match has been found, the FormsAuthentication.RedirectFromLoginPage() method is called. This will result in the program execution proceeding to the desired content page. If the login is incorrect, a message that alerts the user to the problem is displayed. The source code for this part of the application can be seen in Listing 18.1.

Listing 18.1 The Authentication Code That Is Triggered when the Button Is Pressed
 private void Button1_Click(object sender, System.EventArgs e)  {    String strName = TextBox1.Text.ToUpper();    String strPassword = TextBox2.Text.ToUpper();    if( ( strName == "JOHN" && strPassword == "DOE" )        ( strName == "SALLY" && strPassword == "SCHMOH" )       ( strName == "CHUCK" && strPassword == "WAGON" )       ( strName == "CHIP" && strPassword == "MUNK" ) )    {      FormsAuthentication.RedirectFromLoginPage( TextBox1.Text,        CheckBox1.Checked );    }    else    {      Label4.Text = "The name/password you entered was incorrect!";    }  } 

You can see the WebForm1.aspx page in Figure 18.3. This comes up after the user has entered the proper authentication credentials.

Figure 18.3. Although there isn't much content on this page, your applications might have areas with content that must be restricted.


The last thing I added to this demo application was the capability to log out. The following code shows how you can log out from this demo application:

 private void Button1_Click(object sender, System.EventArgs e)  {    FormsAuthentication.SignOut();    Response.Redirect( "login.aspx" );  } 

Although the FormsAuthentication class is easy to use in most cases, you might find several properties and methods useful that go beyond the basic authentication. Table 18.1 shows the two properties that are available, and Table 18.2 shows the methods that are available.

Table 18.1. FormsAuthentication Public Static (Shared) Properties




Returns the configured cookie name used for the current application.


Returns the configured cookie path used for the current application.

Table 18.2. FormsAuthentication Public Static (Shared) Methods




Attempts to validate the credentials against those contained in the configured credential store, given the supplied credentials.


Returns an instance of a FormsAuthenticationTicket class, given an encrypted authentication ticket obtained from an HTTP cookie.


Produces a string containing an encrypted authentication ticket suitable for use in an HTTP cookie, given a FormsAuthenticationTicket .

GetAuthCookie (Overloaded)

Creates an authentication cookie for a given user name.


Returns the redirect URL for the original request that caused the redirect to the logon page.


Given a password and a string identifying the hash type, this routine produces a hash password suitable for storing in a configuration file.


Initializes FormsAuthentication by reading the configuration and getting the cookie values and encryption keys for the given application.

RedirectFromLoginPage (Overloaded)

Redirects an authenticated user back to the originally requested URL.


Conditionally updates the sliding expiration on a ticket.

SetAuthCookie (Overloaded)

Creates an authentication ticket for the given user name and attaches it to the cookie's collection of the outgoing response. It does not perform a redirect.


Removes the authentication ticket by doing a SetForms with an empty value, given an authenticated user. This removes either durable or session cookies.

File Authorization

File authorization is performed by the FileAuthorizationModule and is active when you use Windows authentication. It does an ACL check to determine whether a user should have access. Applications can further use impersonation to get resource checks on resources that they are accessing.

URL Authorization

URL authorization is performed by the URLAuthorizationModule , which maps users and roles to pieces of the URI namespace. This module implements both positive and negative authorization assertions. That is, the module can be used to selectively allow or deny access to arbitrary parts of the URI namespace for certain sets, users, or roles.

The URLAuthorizationModule is available for use at any time. You only need to place a list of users and/or roles in the <allow> or <deny> elements of the <authorization> section of a configuration file.

To establish the conditions for access to a particular directory, you must place a configuration file that contains an <authorization> section in that directory. The conditions set for that directory also apply to its subdirectories, unless configuration files in a subdirectory override them. The general syntax for this section is as follows:

 <[element] [users] [roles] [verbs] /> 

The element is required. Either the users or the roles attribute must be included. Both can be included, but both are not required. The verbs attribute is optional.

The permissible elements are <allow> and <deny> , which grant and revoke access, respectively. Each element supports three attributes, which are defined in Table 18.3.

Table 18.3. The <allow> and <deny> Attributes




Identifies a targeted role for this element. The associated IPrincipal object for the request determines the role membership. You can attach arbitrary IPrincipal objects to the context for a given request and they can determine role membership in whatever fashion you like. For example, the default WindowsPrincipal class uses Windows NT groups to determine role membership.


Identifies the targeted identities for this element.


Defines the HTTP verbs to which the action applies, such as GET , HEAD , or POST .

Anonymous users are also denied.

The following example grants access to Jim, while denying it to Bob:

 <authorization>     <allow users="Jim"/>     <deny users="Bob" />     <deny users="?" />  </authorization> 

You can use a comma-separated list, such as the following, to indicate that both users and roles can refer to multiple entities:

 <allow users="Jim, Bob, jsventures\office" /> 

Notice that the domain account ( jsventures\office ) must include both the domain and username combination.

In addition to identity names , there are two special identities, as shown in Table 18.4.

Table 18.4. Special Authentication Identities




Refers to all identities.


Refers to the anonymous identity.

To allow Bob and deny everyone else, one might construct the following configuration section:

 <authorization>     <allow users="Bob" />     <deny users="*" />  </authorization> 

The following example lets everyone do a GET , but only Billy can use POST :

 <authorization>     <allow verb="GET" users="*" />     <allow verb="POST" users="Billy" />     <deny verb="POST" users="*" />  </authorization> 

Rules are applied using the following heuristics:

  • Rules at lower levels take precedence over rules at higher levels. The system determines which rule takes precedence by constructing a merged list of all rules for a URL, with the most recent ( nearest in the hierarchy) rules at the head of the list.

  • Given a set of merged rules for a URL, the system starts at the head of the list and checks rules until the first match is found. Note that the default configuration for ASP.NET contains an <allow users="*"> element, which authorizes all users. If no rules match, the request is allowed unless otherwise denied. If a match is found and the match is a <deny> element, it returns 401 . Applications or sites can easily configure a <deny users="*"> element at the top level of their site or application to prevent this behavior.

  • If an <allow> matches, the module does nothing and lets the request be processed further.

  • There is also a <location> tag that you can use to specify a particular file or directory to which settings wrapped by that tag (between <location> and </location> tags) should apply.

Passport Authentication

Microsoft offers a single logon and core profile service for member sites in a centralized authentication service called passport authentication . The user no longer must log on to use new protected resources or sites. For your site to be compatible with passport authentication and authorization, you should use this provider.

Here is a sample conversation that shows what forms-based authentication (passport authentication) looks like:

  1. Because the request does not contain a valid passport ticket (form), the server must return 302 and then redirect the client to the passport Logon Service. This bypasses the encrypted parameters describing the original request on the query string.

  2. The client is redirected, after which the client issues an HTTP GET request to the logon server with the supplied query string.

  3. The client is presented with a logon form by the passport logon server.

  4. The client, using Secure Sockets Layer (SSL), then fills out the form and does a POST back to the logon server.

  5. After the Logon server authenticates the user, it redirects back to the original URI ( The authentication ticket is encrypted in the query string.

  6. With the ticket encrypted on the query string, the client is redirected and asks for the original protected resource.

  7. Because the PassportAuthenticationModule on the originating server detects the presence of the ticket on the query string and the absence of the form, it then can issue the authentication form. The request is then authenticated.

Later requests to the site for the protected resources are authenticated at the originating server using the supplied ticket. Because tickets can expire, or reused tickets on other member sites might be used, passport authentication can make provisions to prevent such things.

One nice thing about passport authentication is that when a member site registers with passport it is given a site-specific key. Passport uses the Triple DES encryption scheme. The site-specific key is used by the passport logon server to encrypt and decrypt the query strings passed between sites.

If you choose to use passport authentication, you first must register your site with the passport service. After registering, you have to accept the license agreement and then install the passport SDK before you can use passport.

The wrapper provided by PassportAuthenticationModule is around the passport SDK for ASP.NET applications. It also provides services and the information profile. PassportIdentity is a IIdentity-derived class that is used to access profile information.

Attaching a custom IPrincipal object to the context is the main purpose of handling the PassportAuthentication OnAuthenticate event, just the same as with WindowsIdentity . The profiler ( PassportIdentity ) lends an interface to the passport profile information as well as methods to decrypt and encrypt passport authentication tickets.

To implement passport authentication in an ASP.NET application, follow these steps:

  1. Download, install, and configure the passport SDK from You must register and pay a fee to obtain the SDK.

  2. Set up passport as the authentication mode in the application configuration file as follows:

     <authentication mode= "Passport">  </authentication> 
  3. Using the passport documentation and the passport SDK functionality, implement Passport authentication and authorization.


Special Edition Using ASP. NET
Special Edition Using ASP.Net
ISBN: 0789725606
EAN: 2147483647
Year: 2002
Pages: 233 © 2008-2017.
If you may any questions please contact us: