Using Basic Authentication

Although you should not use Basic authentication with .NET or in any public Web application except in conjunction with Secure Sockets Layer (SSL) encryption or some other strong encryption mechanism, it's a useful exercise so that you understand the benefits of the authentication methods that IIS, IE, and .NET provide.

Note Before you start, open the CSharpASP Properties dialog using the Internet Services Manager application and make sure that Anonymous Access and Integrated Windows Authentication are disabled, and Basic Authentication is enabled. You must have at least one authentication method enabled or IIS will deny all access to the application. However, you may have more than one authentication method enabled simultaneously. After doing this you may need to authenticate to open or edit the project in VS.NET.

Note In your web.config file, make sure the authentication mode is set to

"Windows" (<authentication mode="Windows">).

Warning When you turn off Integrated Windows Authentication, you may no longer be able to debug your application by running it in Debug mode. However, you can debug by writing output messages or by attaching to the running aspnet_wp.exe process. To do that, click the Debug menu, select Processes, highlight the aspnet_wp.exe process, and click the Attach button. Run the project, and then launch a browser and make the request, and ASP.NET will break into the debugger at any breakpoints you set.

The process to set up Basic authentication is simple.

1. When the server receives a request, it sends an access denied message. The user must log on with a valid domain account and password to get entry to the application.

2. When the user has been authenticated, you can further restrict access by checking the value of the Request.ServerVariables["AUTH_usER"] variable, which will contain the username for the authenticated account. The Request.ServerVariables["AUTH_PASSWORD"] variable contains the user's password. By comparing the username to an access list, you can deny access to specific individuals.

The Web Form ch18-1.aspx contains an example. When you request the page for the first time, you'll see the username/password dialog and a custom message. Enter the name and password of a valid network account. If the values you enter map to a valid account, you'll see the ASPSessionID for this session and the message User authorized, followed by the information in the auth_user, AUTH_PASSWORD, and LOGON_USER variables in the Request.ServerVariables collection. I've included these three variables so you'll understand why Basic authentication is dangerous. Remember that anyone along the route from the client to the server can intercept the request and steal the username and password information. You should not use this method to secure your site.

The Web Form ch18-1 contains very little code (see Listing 18.1). It creates a user variable, assigns it the contents of the Request.ServerVariables["LOGON_usER"] variable, and then checks to see if the user variable contains a null string. If so, it denies access by returning a 401 (access denied) status code and a custom error message. Some browsers, such as IE, use the custom error message in the username/password dialog.

Listing 18.1: Domain Authentication with Basic Authentication Based On the logon_user HTTP Variable Value (chl8-l.aspx.cs)

// autogenerated code omitted public class ch18 1 : System.Web.UI.Page {

protected System.Web.UI.WebControls.Label lblAuthorized; protected System.Web.UI.WebControls.Label lblResult;

private void Page Load(object sender, System.EventArgs e) { String s=""; _

s = Request.ServerVariables["HTTP_AUTHORIZATION"];


if (!this.User.Identity.IsAuthenticated) {

Response.Status = "401 Unauthorized"; Response.AddHeader("WWW-Authenticate",

"BASIC REALM=\"You are not authorized to " + "access this resource.\""); s = "LOGON_USER=" + this.User.Identity; s += "AUTH_USER=" + Request.ServerVariables.Get

("AUTH_USER") + "<br>"; s += "AUTH_PASSWORD=" + Request.ServerVariables.Get

("AUTH_PASSWORD") + "<br>"; lblResult.Text = s; this.lblAuthorized.Visible=false;

foreach(String aKey in Request.ServerVariables.Keys) { Response.Write(aKey + "=" +

Request.ServerVariables[aKey] + "<br>");

s = "LOGON_USER=" + Request.ServerVariables.Get

("LOGON_USER") + "<br>"; s += "AUTH_USER=" + Request.ServerVariables.Get

("AUTH_USER") + "<br>"; s += "AUTH_PASSWORD=" + Request.ServerVariables.Get

("AUTH_PASSWORD") + "<br>"; lblResult.Text = s; this.lblAuthorized.Visible=true;

Figures 18.5 and 18.6 show the authentication sequence.

J^i'j ■ i e « i.aic a 4 a JJ * _jJ^^j^Jk d Figure 18.5: Initial request for the Web Form ch18-1.aspx. Request denied; browser displays login dialog

Figure 18.6: The user entered a valid usermane/password combination

Because you have no control over how a user reaches a page in your application, you must check authentication for every page in your application for which you want to restrict access. Therefore, the simplest place to perform the check is in the global.asax file in the Application_BeginRequest event. However, you don't need to perform the full check for every request, and rather than displaying some information after authenticating the client, you don't need to do anything—ASP.NET automatically continues the request with the code in the requested page.

Although I'm not going to show you a working example, it's easy to understand, based on the code you saw in the last chapter, that you can set an in-memory cookie (for sessionless applications) or a Session variable after the user has authenticated the first time. If the cookie or Session variable has a value, then the user is authenticated, and you don't need to perform any more checks.

Was this article helpful?

0 0

Post a comment