LANGUAGES: VB.NET | C#
ASP.NET VERSIONS: 2.0 (Beta 2)
Secure Your Site
With the new login controls of ASP.NET 2.0
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.
Click here to learn more about the other great new controls
of ASP.NET 2.0.
This article was originally published in
ASP.NET Pro Magazine.