• Choose a category
• All
• Classic-Fiction

Today, Forms authentication is the most commonly used way to collect and validate user credentials—for example, against a database of user accounts. The login pattern implemented by Forms authentication doesn’t look radically different from Windows authentication. The key difference is that with Forms authentication everything happens under the strict control of the Web application.

You set up an ASP.NET application for Forms authentication by tweaking its root web.config file. You enter the following script:

The section indicates the URL of the user-defined login form. ASP.NET displays the form only to users who have explicitly been denied access in the section. The ? symbol indicates any anonymous, unauthenticated users. Note that the anonymous user here is not the IIS anonymous user but simply a user who has not been authenticated through your login form.

All blocked users are redirected to the login page, where they are asked to enter their credentials.

Note

The Forms authentication mechanism protects any ASP.NET resource located in a folder for which Forms authentication and authorization is enabled. Note that only resource types explicitly handled by ASP.NET are protected. The list includes .aspx, .asmx, and .ashx files, but not plain HTML pages or classic ASP pages. In IIS 7.0, though, you are given the tools to change this by setting a Web server-level web.config file where you assign new resources to the ASP.NET standard HTTP handler.

Forms Authentication Control Flow

Form-based authentication is governed by an HTTP module implemented in the FormsAuthenticationModule class. The behavior of the component is driven by the contents of the web.config file. When the browser attempts to access a protected resource, the module kicks in and attempts to locate an authentication ticket for the caller. By default, a ticket is merely a cookie with a particular (and configurable) name. However, it can be configured to be a value embedded in the URL. In this case, we talk about cookieless Forms authentication.

If no valid ticket is found, the module redirects the request to a login page. Information about the originating page is placed in the query string. The login page is then displayed. The programmer creates this page, which, at a minimum, contains text boxes for the user-name and the password and a button for submitting credentials. The handler for the button click event validates the credentials using an application-specific algorithm and data store. If the credentials are authenticated, the user code redirects the browser to the original URL.

The original URL is attached to the query string of the request for the login page, as shown here:

http://YourApp/login.aspx?ReturnUrl=original.aspx

Authenticating a user means that an authentication ticket is issued and attached to the request. When the browser places its second request for the page, the HTTP module retrieves the authentication ticket and lets the request pass.

Let’s see how Forms-based authentication works in practice and consider a scenario in which users are not allowed to connect anonymously to any pages in the application. The user types the URL of the page—say welcome.aspx—and goes. As a result, the HTTP module redirects to the login page any users for which an authentication ticket does not exist, as shown in Figure 19-3.

Figure 19-3. A sample login page.

Important

There are inherent security concerns that arise with Forms authentication related to the fact that any data is transmitted as clear text. Unfortunately, with today’s browser technology, these potential security concerns can be removed only by resorting to secure channels (HTTPS). I’ll return to this topic later in the General Security Issues section.

Collecting Credentials Through Login