Industry Review by Dino Esposito

Profile: Dino Esposito is a trainer and consultant based in Rome, Italy. Member of the Wintellect team, Dino specializes in ASP.NET and ADO.NET and spends most of his time teaching and consulting across Europe and the United States. Prolific author, Dino writes the "Cutting Edge" column for MSDN Magazine and contributes to the Microsoft's ASP.NET DevCenter and several other magazines. Recent books are Programming Microsoft ASP.NET (Microsoft Press, 2003), Applied XML Programming with the .NET Framework (Microsoft Press, 2002), and Introducing ASP.NET 2.0, also from Microsoft Press. When not writing or teaching, Dino is likely speaking at industry events such as Microsoft TechEd, DevConnections and WinDev.

Zero Code, Extra Services: Is .netPROTECT the Perfect Fit for Real-World ASP.NET Authentication?

More often than not, developers of Web applications face the need of building an authentication mechanism to protect some of the resources their site handles and serves to users. To simplify the development of this common layer of code, Microsoft introduced Forms Authentication originally with the first release of ASP.NET, back in early 2002. Defined, Forms Authentication is a security mechanism that authenticates a user by asking her to type credentials into a login Web form. Typically, credentials consist of a user name and a password.

ASP.NET Forms Authentication is a built-in engine that sits on top of the application and checks to see whether the connected user has logged in. If not, the engine redirects the user to a login page. Once successfully authenticated, the user is then redirected to the originally requested page. This piece code is not hard to design and write per se; it’s just boring, repetitive, and hardly manageable as you need to have it sit at the very top of each and every page to protect. The code would look for any authentication cookie attached to the request and redirect the request, or let it pass, as appropriate. ASP.NET makes a good job in factoring this code out and burying it in the folds of the system components. Is this perfect as is? How much can it be improved? And in which direction?

ASP.NET 2.0 brings significant changes to the Forms Authentication engine to make it less boring and more simple to code and more flexible to implement. It won’t change one key fact: Forms Authentication is mostly developer-focused meaning that any new feature can only be achieved through code.

Today, there’s a different approach you can take that passes through a new product—.netPROTECT—built on over 4 years of direct experience with massive real-word authentication solutions. The focus of this product is different as .netPROTECT is more an application layer than a pluggable component. You install it, and it will protect your site (even multiple sites hosted on the same machine) with zero lines of code. It’s flexible and highly customizable, but all of its features are configured through a Web interface and administratively.

Where .netPROTECT Fits In

To authenticate users, ASP.NET developers have to write login pages and implement their own data access code to check credentials and roles. Compared to classic ASP, it is a quantum leap; from an higher-level outlook, instead, it is much less enticing. You still have to write a good amount of code—checking the credentials, securing passwords, configuring the data storage (be it a database or perhaps Active Directory). In addition, you have to deal with user interface, handle events, and configuration files. Let’s be honest: it is neither a mess, nor a pleasure. And there’s more yet.

ASP.NET Forms Authentication suffers from another key limitation that is important to know, although many people tend to blissfully overlook it. Forms Authentication, as it is implemented in ASP.NET 1.x and in the future 2.0 version, protects only (repeat, only) ASP.NET files. The list counts all and only the files that are mapped to ASP.NET in the IIS metabase and includes ASPX, ASMX, ASCX, ASAX, and any other custom extension that is mapped to ASP.NET at the IIS level.

In other words, ASP.NET Forms Authentication doesn’t protect your HTML, JPEG or perhaps Word and Excel files. The feature is by design; it’s not a mere bug. The ASP.NET runtime never handles, and therefore cannot intercept, any request targeted to resources that are out of its reach. By default, HTML or JPEG files are handled by IIS in person, and should be explicitly redirected to ASP.NET to make them pass through the authentication mechanism.

What’s .netPROTECT, anyway? And how does it fit in the ASP.NET authentication scenario? At its core, .netPROTECT is an enhanced Forms Authentication mechanism that works automatically, doesn’t require code, and is not even vulnerable to the ASP.NET security canonicalization hole. More precisely, .netPROTECT is a high end password protection, user management and authentication solution for ASP.NET. It enables you to quickly and easily protect areas of your web site with passwords.

With .netPROTECT, in fact, you don’t write a single line of code as far as authentication is concerned; you are free to focus on the core functionality of the pages and have at disposal the .netPROTECT object model to check users against roles and privileges. A second aspect of .netPROTECT that is vitally important are the additional features it provides far beyond “raw” authentication and the Web administration environment.

What You Can Do With .netPROTECT

.netPROTECT is thought as a full replacement of classic ASP.NET Forms Authentication and should be used instead of it and not together with it. The product password-protects individual files and entire directories with a single password protection entry. Implemented as an ASP.NET HTTP module, it kicks in whenever a request for any ASP.NET resource comes in. The URL of the request is checked against the database of protected resources and a customizable login page is displayed if appropriate.

FIGURE 1—The default but customizable login form of .netPROTECT

The user’s credentials and roles are cached and made available to the page code via a proprietary object model. In the end, with .netPROTECT you work with an alternate API that is richer and more powerful than the classic Forms Authentication API of ASP.NET.

By using .netPROTECT you don’t have to worry about building your own database for storing users, groups, passwords, roles and whatever. Neither should you spend some time writing an access API for this data store. The product has no special installation requirements and works great in shared hosting environments (even in medium trust!). The great news is that if your Web host supports ASP.NET, in most cases you just copy .netPROTECT’s files to the site and start using it.

Although .netPROTECT was originally designed for ASP.NET 1.x, it somehow anticipates some of the hot new features coming up with ASP.NET 2.0. For instance, .netPROTECT allows you use a variety of databases to store user’s credentials. You get native database support for SQL Server, Access, MySQL, and Oracle. Now there is a native ASP.NET 2.0 version with advanced features for internationalization.

By applying a slick trick you can extend the protection capabilities of .netPROTECT well beyond the set of resources normally bound to the ASP.NET engine. If you rename your HTML, JPEG, or Word files to have a trailing .aspx extension you automatically bind them to the ASP.NET pipeline and have .netPROTECT to intercept them. It should be noticed that in this way you’ll incur some additional overhead when accessing the files, but at least you’ll be able to protect them. With the latest ASP.NET 2.0 version and IIS 7 you will be able to protect all content without using the handler.

The best of .netPROTECT, though, lies elsewhere: administration system, password management, filters, reporting and auditing.

Administering the Membership System

.netPROTECT includes a comprehensive administration system for managing all aspects of your membership system. Once you install the product, by pointing the browser to the /admin folder below the root of your site, you’ll enter the central console to administer the site, its users, their passwords and roles.

FIGURE 2—The administrative console of .netPROTECT

You’ll also find wizards for customizing login, logout forms and password-related forms. Not only can you modify the template of form, but even add custom fields and specify the types of controls to be used to collect data for these fields.

You exercise complete ownership tracking of all users, groups and protected areas, search users using any criteria, and create any hierarchy of privileges between groups of users. A number of security best practices are supported as well. You can control (and block if necessary) concurrent logins, that is multiple logins using the same nickname at the same time. You can set quotas on a per site, per user or per group basis, and automatically disable users that exceed a given threshold. To prevent dictionary attacks, you can set a limit on the hits, logins per time, and block login attempts.

In addition to sending automated emails when a password is forgot or changed, .netPROTECT also hosts a comprehensive mail engine that allows you to email to any individual user, group or selection of users any message text. For example, you can search for all users who expire in less than 5 days and offer a special incentive to renew. Likewise, you can configure the system to email all users who have expired passwords and send them a link to the password update page. All this—it is worth repeating—comes at the cost of no lines of code.

With classic Forms Authentication you must edit configuration files for each application when protecting new areas. With .netPROTECT, you can just add a new entry through the Web interface (see Figure 3) to protect a specific file, directory or directory with all subdirectories and files. It is a simple point but considering the work required to do this normally can be significant.

FIGURE 3—Adding a new protected area to .netPROTECT

Through roles, .netPROTECT supports advanced sub-management functionality so that you can provide administrators of subsystems in a large organization the ability to manage just their own protected area. The main administrator would see everything, but the sub-administrator would see only a subset of the options. The same feature is also available for group management where an individual could only manage a specific group. Role management in .netPROTECT is actually very powerful, and you can define your own roles as well.

The Password Management System

A membership system can’t help but providing a minimum set of password-related features. This certainly includes password recovery. Users who forgot their passwords can request a new one which will be automatically generated and emailed to them. Similarly, users can go to a specific page and launch a password-change wizard. All passwords are stored in a hashed form using a one-way cryptographic algorithm. The Web console allows administrators to set the minimum length of the passwords and its composition (number of digits, number of symbols and number of mixed case characters).

Previously used passwords can be tracked and blocked to enhance security. If you enable this feature users won’t be able to set their password to the same string used over the past n password changes. Password expiration can be controlled on a per user basis if necessary.

If you’ve been thinking so far that .netPROTECT was a mere replacement for ASP.NET Forms Authentication, now consider that none of these additional features are supported in neither ASP.NET 1.x nor ASP.NET 2.0. An effective password management system for ASP.NET applications can only be coded manually or inherited through a product like .netPROTECT.

FIGURE 4—Managing a registered user

Intrusion Prevention

.netPROTECT can be configured to prevent or restrict access to a given site or protected area based on a set of custom criteria that may include IP address, user agent, or other headers. An administrator can control the restrictions in place and establish if violations should be treated with an error message or a redirection to a particular page.

Autologins are supported too. Autologin allows for users in a well-known group to be automatically authenticated against the system without typing their credentials in. A typical scenario in which this feature might be usefully enabled is to facilitate the login of users coming from a given set of IP addresses within the local intranet. Each autologin entry can be assigned a particular user context so that logging, auditing and reporting functions remains possible even on those who autologin.

In addition, login redirection is supported with token support. This means you can automatically have users redirect to a directory, page or querystring including their name with a simple administrative setting an no additional code.

Reporting and Auditing Features

In .netPROTECT, auditing and reporting capabilities live side by side. The product supports audit trail, meaning that it can provide a detailed record of who has accessed which pages and what operations he or she has performed during a given period of time. You can track each page requested and see user details, the time at which the user logged in and out and even more.

.netPROTECT also features a “live user” report which provides a snapshot of all the users being currently connected to the system with their username, number of concurrent access on the nickname, first and last login.

The wealth of information and statistics collected by the system can be visualized in charts of various types, and organized by sign-ups, logins, hits, top users, top groups. Statistical data can be archived on demand and retrieved from the data store at a later time.

Setup, Deploy, and Configure .netPROTECT

To use .netPROTECT you simply copy the installation files in your Web site’s root and make sure that the dotnetprotect.dll assembly go to the Bin folder of the application. As mentioned, this assembly contains a HTTP module that must be registered with the application’s web.config file to start hooking up requests.

<system.web>
  <httpModules>
    <add name="ProtectionModule"
      type="dotnetPROTECT.ProtectionModule, dotnetprotect" />
  </httpModules>
</system.web>

In addition, you should also add a couple of redirector handlers to make sure that the admin.aspx page displays correctly and all ASPX resources are handled by the module. The product ships with a web.config file that you only have to fuse to the one you’re using for your application. Actually, these settings are done for your automatically if you just deploy to your site but may be required if you are integrating with a site that already has a web.config setup.

With .netPROTECT, it is also possible to protect multiple applications within one server with a single .netPROTECT implementation. To get this, though, the <machineKey> setting needs be unique to the machine and should not isolate applications on the same machine. (This is the default setting in ASP.NET 1.1 but not in ASP.NET 1.0). If you don’t do this, it would be impossible for the system to detect authentication cookies issued for different applications.

<system.web>
  <machineKey validationKey="AutoGenerate"
    decryptionKey="AutoGenerate" validation="SHA1" />
</system.web>

Using .netPROTECT you can access an object model centered around the ProtectionManager object. Here’s an example of how to write a page that access membership information.

void Page_Init(Object sender, EventArgs e)
{
  Response.Write(ProtectionManager.Manager.CurrentUser.Name);
  Response.Write(ProtectionManager.Manager.CurrentUser.ID);
}

The ProtectionManager object exposes any information about the current user so that you can show it in your pages if needed.

Summary

ASP.NET Forms Authentication is definitely a time-saving feature. As implemented in ASP.NET 1.x, though, it forces you to write the code that collects and validates the user’s credentials. While this approach gives you the maximum of flexibility—you can use nearly any data store, from SQL Server to Oracle and MySQL—it doesn’t deliver a rich environment with rich and powerful functions.

.netPROTECT falls somewhere in the middle. It is designed to replace the standard Forms Authentication mechanism of ASP.NET with a highly customizable and rich environment that offers password management, auditing, reporting, and administration features. As a developer you can’t control the physical process that validates the supplied credentials, but you inherit a lot of admin-level features and the certainty that the user credentials are stored and retrieved using industry best practices.

Finally, .netPROTECT works side by side with regular ASP.NET Forms Authentication, according to the following rule. First .netPROTECT authenticates the requesting user, then it lets Forms Authentication pop up its login page. This is a good feature for those wanting some small sections of their site to still use forms auth for some simple hardcoded protection or legacy parts of their site.