ControlFreak

LANGUAGES: VB.NET | C#

ASP.NET VERSIONS: 2.0 (Beta 2)

 

Secure Your Site

Using the new Login Controls in ASP.NET 2.0

 

By Steve C. Orr

 

The new Login controls and Membership API in ASP.NET 2.0 provide a powerful and automated way to securely store and manage user credentials. Together, they eliminate nearly all the boilerplate user management code that you ve likely written many times before. This new system goes a long way toward Microsoft s .NET 2.0 goal of a 70% reduction in the amount of code needed to write an application.

 

To explore these robust new capabilities, create a new Web site using Visual Studio 2005. Under the WebSite dropdown menu select ASP.NET Configuration. A page similar to that shown in Figure 1 will appear. Using this configuration tool, you may never need to manually edit a web.config file ever again! It acts as a front end for editing the web.config file and managing other standard settings, such as the focus of this article: security.

 

Figure 1: You may never need to open another web.config file ever again. Built-in administration screens make it easy to configure Web site settings and manage users.

 

The screen shown in Figure 1 says that an Access database will be used to store the security settings by default, but this is untrue in Beta 2. Instead, the settings are now stored in a SQL Express database by default. This database is named ASPNETDB.MDF. You can interact with this database like any other database, from the Data Connections node of the Server Explorer window of Visual Studio. Alternate membership providers can be specified on the Provider tab. Custom providers can optionally be developed in case you d like to wrap a legacy authentication system or roll your own.

 

By default, new Web sites use Windows Authentication, which is great for an intranet application. This fictional example will be accessed from the Internet, so Forms Authentication will be used instead (see Figure 2).

 

Figure 2: Windows Authentication is enabled for Web sites by default, but Forms Authentication is more appropriate for Web sites that will be accessed from the Internet.

 

Figure 3 shows a site for which three roles have been established. The majority of users would belong to the User group. The elevated Premium group might be for paying subscribers, providing them with enhanced functionality. The Admin group will be for administrators only. Of course, you can establish whatever roles are most appropriate for your Web site.

 

Figure 3: Three roles have been created in this example: User, Premium, and Admin.

 

After roles have been created, you ll probably want to add one or more users. This can also be done through the same built-in Web site configuration tool, as shown in Figure 4. A strong password must be specified, so passwords such as abc or password are rejected. Notice that the three roles configured here each have a checkbox, indicating that a user can be a member of one or more roles. It would be nice if there were a way to configure these to be option buttons, so that only one group could be specified. It would also be nice if there were a way to establish hierarchies, such as specifying that administrators are automatically members of the User group, but custom validation code still has to be written to enforce such matters.

 

Figure 4: New users can be added through this built-in administration screen, so you aren t forced to re-create such boilerplate code.

 

Rules can be established for the folders within a Web application to allow or deny access to users and/or roles. Figure 5 shows an Admin folder that grants access to members of the Admin role, but denies access to all others.

 

Figure 5: Rules can be established for the folders within a Web application to allow or deny access to users or roles.

 

Now that a basic security framework has been established for the Web site, let s put together some pages that take advantage of it.

 

Secure Your Site with Login Controls

There s a new set of controls in the Visual Studio 2005 toolbox (under the Login tab). These seven controls automatically interact with the membership settings configured earlier in this article, so they work from the moment you drag them onto the page (see Figure 6). In most cases, little or no code will need to be written to achieve a fully authenticated software system. All of these controls have a SkinID property and an EnableTheming property that allows a custom look to be applied consistently across controls and pages.

 

New Login Controls	Description
Login	Provides a username and password textbox, associated labels, a working remember me checkbox, validation functionality, and a plethora of customization options.
LoginStatus	Automatically determines whether it should display a Login hyperlink or a Logout hyperlink based on the user s current authentication status.
LoginView	Displays varying configurable sets of controls based on the user s current authentication status, optionally considering any roles to which the user may belong.
ChangePassword	Provides a standard Password, New Password, and Verify Password screen that works with no custom code required.
PasswordRecovery	Provides a way for users to retrieve forgotten passwords.
LoginName	Displays the user s login name when they re authenticated; otherwise, it s invisible.
CreateUserWizard	Provides one or more wizard steps to automatically collect user registration data.

Figure 6: These seven new Login controls in ASP.NET 2.0 dramatically simplify user management and authentication.

 

Create a new Web page named Login.aspx . Drag a Login control onto this page. This control, shown in Figure 7, provides a User Name and Password textbox, associated labels, a working remember me checkbox, validation functionality, and a plethora of customization options. You ve probably constructed similar login screens many times before, and doing so will be simpler than ever now that the Login control is around to manage such matters.

 

Figure 7: The Login control provides all the functionality needed to allow users to log into a Web application, and it s highly adaptable in case you need to customize it.

 

The smart tag shown in Figure 7 allows easy configuration, such as automatic formatting and the option to convert the control to a template. Templates are much more intuitive than they used to be, now that they re visually editable in the designer.

 

All of the text displayed by the Login control can be customized via properties, and additional instruction text can be specified, if necessary. You can set the VisibleWhenLoggedIn property to False for situations where you d like to have the Login control on all your pages, but only when relevant. You can have the control include hyperlinks to other pages, such as a forgotten password page, a help page, or an account creation page. In all, the Login control provides more than 50 properties that allow various forms of customization. Needless to say, this is a highly flexible control.

 

The LoginStatus control acts as a simple hyperlink at run time. If the user is not logged in, it provides a hyperlink to the login page. If the user is logged in, it provides a hyperlink that automatically logs them out. You can configure the hyperlink text, the action the control will take upon logout, and all the URLs involved. The LogoutAction property accepts one of three values: Refresh, Redirect, or RedirectToLoginPage.

 

The LoginView control displays configurable sets of controls depending on the user s current login status. For example, it can display one set of controls for logged-in users, and a different set of controls for anonymous users. Additionally, it can display different sets of controls for any roles that may have been configured. For example, it can display one set of controls for administrators, and another set of controls for standard users. The smart tag for the control allows you to configure the different roles that the control will handle.

 

The LoginName control simply displays the name of the logged-in user. This control is invisible when the current user is anonymous. The FormatString property allows the output to be customized; for example, apply the string Welcome, {0}! to welcome the user by name.

 

Any decent authentication system must also provide a way to deal with forgotten passwords. The PasswordRecovery control (illustrated in Figure 8) provides rich functionality that permits a user to retrieve a forgotten password. By default, the control will e-mail a forgotten password to the user s registered e-mail address after they ve successfully answered the secret question that was established upon registration. For this to work, you must specify a <MailDefinition> child element within the control definition:

 

<MailDefinition From="Steve@Orr.net"/>

 

Additionally, the application s SMTP settings must be configured. This is done most easily through the Web site administration tool described earlier.

 

Figure 8: The PasswordRecovery control provides a way for users to retrieve forgotten passwords.

 

Good security measures include changing passwords regularly. The ChangePassword control (shown in Figure 9) provides all the functionality you re likely to need in this regard. It provides a screen similar to many you ve seen before, with a textbox to enter the current password, a textbox to enter the new password, and a third textbox to confirm the new password. Validation is built in, and a NewPasswordRegularExpression property allows the developer to declaratively require that all new passwords match any pattern imaginable. By default this control will only accept strong passwords.

 

Figure 9: The ChangePassword control provides standard Password, New Password, and Confirm New Password options that work with no custom code required.

 

The ChangePassword control is completely configurable, with every bit of text exposed publicly through properties and methods. In case that s not enough customization, the entire control can be converted to a template via the context menu in the Visual Studio 2005 designer.

 

The CreateUserWizard control is the most functionally-rich Login control of them all. It walks users through the steps involved in establishing a new user account. This highly extensible control can be configured to collect unlimited amounts of data about new users. It can send confirmation e-mails and define user roles. Because it inherits from the new Wizard control, it provides the same level of extensibility. As many steps can be added to the wizard as are needed, and each step can be individually configured via properties or converted into templates for unlimited levels of customization. Therefore, this control can meet the requirements whether a quick and dirty solution is needed or whether extensive amounts of detailed user information need to be collected.

 

The boolean LoginCreatedUser property specifies whether a new user should be automatically logged in after they ve registered. The DisableCreatedUser property specifies that new user registrations should not become active until they ve been approved.

 

The Infrastructure Below

Clearly the whole set of Login controls are quite powerful, but what if you prefer not to use them? The whole membership infrastructure underlying the Login controls is public, and loosely coupled to the controls. This means that you don t need to use the Login controls, because you can directly call the same underlying methods that these controls use.

 

For example, say you ve got your own user interface and decided to not use the Login control. You can still easily use the underlying membership system to authenticate a user with one line of code:

 

If System.Web.Security.Membership.ValidateUser(UN, PW) Then _

 

The System.Web.Security namespace contains a variety of useful and extensible functions. It contains only static methods (known as shared methods in VB) so no object instantiations are needed.

 

Perhaps you d love to use the Login controls, but have existing authentication code that works just great and you d prefer to keep using it. No problem; the controls can be hooked up to a custom authentication system with little effort.

 

Whether used together or separately, clearly the new Login controls and Membership API are compelling reasons to upgrade to ASP.NET 2.0. Even if you have an existing authentication you d like to continue to utilize, by wrapping it inside a custom membership provider you can provide a standardized interface to your system, thereby increasing reusability and simplifying maintenance.

 

Steve C. Orr is an MCSD and a Microsoft MVP in ASP.NET. He s been developing software solutions for leading companies in the Seattle area for more than a decade. When he s not busy designing software systems or writing about them, he can often be found loitering at local user groups and habitually lurking in the ASP.NET newsgroup. Find out more about him at http://SteveOrr.net or e-mail him at mailto:Steve@Orr.net.