Examining ASP.NET's Membership, Roles, and Profile - Part 1By Scott Mitchell
|A Multipart Series on ASP.NET's Membership, Roles, and Profile|
This article is one in a series of articles on ASP.NET's membership, roles, and profile functionality.
There's one thing messageboard websites, eCommerce websites, social network websites, and portal websites share in common: they all provide user accounts. These websites, and many others, allow (or require) visitors to create an account in order to utilize certain functionality. For example, a messageboard website, like ASPMessageboard.com, allows anonymous and authenticated visitors to view and search the posts in the various forums. However, in order to be able to post a new thread or reply to a message a visitor must have an account and must log into the site.
Providing user account support for a site involves the same set of steps: creating a database table to store user account information,
creating a login page, defining a system by which authenticated users' logged on status is remembered across postbacks, specifying
which pages are only available for authenticated users (authorization), creating a page for visitors to create a new user account,
creating a page for the site's administrators to manage the user accounts, and so forth. Prior to ASP.NET, developers had to decide
how to implement all of these facets on their own. ASP.NET introduced the concept of forms-based authentication, which
FormsAuthentication class to ease signing in and out of a site, as well as a protected authentication
ticket to remember users' logged on status across page requests. (See Simple
Authentication for an article on implementing authentication with classic ASP; refer to Using
Forms Authentication in ASP.NET and Dissecting Forms Authentication
for more information on ASP.NET's forms-based authentication capabilities.)
Even with forms-based authentication, though, ASP.NET developers are still on the hook for defining and creating the structure for storing user account information, for creating login and logout web pages, for enabling visitors to create new accounts and administrators to manage accounts, and so on. Thankfully ASP.NET version 2.0 has lightened developers' loads by providing the membership system and the security Web controls in ASP.NET 2.0. In a nutshell, membership is an API that provides programmatic access to common user account-related tasks. For example, there are methods to create a new user account, authenticate a user's credentials, delete a user, return all user information in the site, and so on. Furthermore, there are a number of security Web controls built atop this API that make performing common user account tasks as simple as dragging and dropping a control on the page.
In this article series we will be examining the ins and outs of version 2.0's membership, roles, and pofile systems and the various security Web controls.
This particular article will examine the basics of membership with a look at configuring and using the built-in
As we will see, this particular provider stores user account information in a pre-defined database schema. Read on to learn more!
Forms-Based Authentication - A Step in the Right Direction, But Too Small a Step
Prior to ASP.NET, web developers were forced to define all of the authentication- and authorization-related decisions. One challenge was how to remember a user's logged on status across web requests; that is, after a user has successfully entered their username and password in the login, when they visit other pages how does the site remember that the user has already logged in? Another challenge was deciding how to protect pages from unauthorized access; that is, how can a page be configured to only allow a particular set of users, or only allow authenticated users? With classic ASP these challenges were usually solved by using a Session variable to remember that a user had successfully logged in across web requests, and code on each page that checked this Session variable to determine the identity of the user visiting the page and whether or not they had access to visit the page.
To help reduce the work needed for implementing user accounts, ASP.NET version 1.0 included support for forms-based authentication
as well as the ability to specify authorization rules in the
Web.config file. The forms-based authentication
provided a means to securely store an authentication ticket as a cookie in the user's browser to remember the user's logged on
status across web requests. The
FormsAuthentication class provides methods for working with this authentication ticket -
both creating the ticket (logging on) and removing it (logging off).
Forms-based authentication aimed to provide a standardized approach for accomplishing two of the common tasks required for implementing
user accounts. Unfortunately, forms-based authentication - on its own - still leaves the developer a lot of work. The developer must
still decide how to serialize user account information, must still build the login page and write code using the
class, must still create a logoff page, a page for creating a new account, a page for managing accounts, and so on.
Not only did this require extra work on the developer's end, but also left important design decisions to the developer, decisions
that might be made that did not follow best practices in design or security. (For example, a user might store users' passwords as
plain-text in the database, rather than hashing or encrypting them. See this article
for more information on the benefits of hashing passwords stored in a database.) The idea of
ASP.NET version 1.0's forms-based authentication was great, but its implementation fell short.
Building On Top of Forms-Based Authentication with ASP.NET 2.0's Membership
Version 2.0 of ASP.NET takes the final step that forms-based authentication in version 1.x didn't - namely, it adds programmatic support for authenticating, adding, creating, deleting, and modifying user account information, along with Web controls for helping with accomplishing these tasks. Forms-based authentication is still alive and well in version 2.0, as well as the authorization settings in
Web.config, and both are used the same way as in version 1.x. What 2.0 adds is the membership API and the security Web controls.
The membership API is implemented using the provider model, meaning that while the interface is well-defined, the actual
implementation can be customized. The .NET Framework includes the
class that contains methods like
ValidateUser(), and others. However, the actual class that
is invoked when the API is used through an ASP.NET web application is based on the configuration of the application. You can
provide your custom user account logic by creating a class that implements the defined membership API, and then configuring the
web application to use your class. Of course you don't need to define a custom class - ASP.NET ships with two built-in membership
providers, one that stores user account information in a SQL Server database, and another that uses Active Directory.
Therefore, the membership system and security Web controls can be used with one of the built-in providers or, if you already have
user data defined in some custom manner, a custom provider can be created so that the custom user store is utilized through the
same API and security controls seamlessly. (See A Look at ASP.NET 2.0's
Provider Model for more information on the concept behind the provider model; in a future article in this series we'll look at
the steps involved in creating a custom membership provider.)
SqlMembershipProvider - Storing User Account Data in a SQL Server Database
One of the two membership providers that ship with ASP.NET 2.0 is the
SqlMembershipProviderprovider, which uses a SQL Server database to store authentication information. In order to use this provider you need to create the database schema used by the provider. There are two ways to accomplish this:
- Use the ASP.NET Website Administration Tool (will create the database schema in a new SQL Server 2005 database file
ASPNETDB.mdf, placed in the application's
- Use the ASP.NET SQL Server Registration Tool (
aspnet_regsql.exe) command-line tool (use this tool to implement the schema in a SQL Server 2000 or 2005 database)
ASPNETDB.mdfthat has the predefined schema. (We'll examine this schema shortly.) You can also use the Website Administration Tool to specify authorization settings. For more on using the Website Administration Tool, see Website Administration Tool Overview, focusing on the Security tab.
If you want to store the user account information elsewhere - perhaps in a SQL Server 2000 database, or a SQL Server 2005 database
not in the
App_Data folder - you'll need to use the ASP.NET SQL Server Registration Tool (
aspnet_regsql.exe) tool. This tool has a graphical
component or can be used through the command-line. The graphical wizard allows you to specify the location to add the needed tables.
For more information on using this tool refer to the technical
|The Effects of the Administration Tool|
When you use the Website Administration Tool to set the authentication type to "From the internet," it adds the following line
to the site's |
If you create the schema through the ASP.NET SQL Server Registration Tool, you'll need to manually add this line to the
SqlMembershipProvider stores user account information in two related tables:
aspnet_Users- has a record for each user account, storing the bare essentials. The
UserIdcolumn uniquely identifies each user in the system, and is stored as a
aspnet_Membership- has a
UserIdcolumn that ties each record back to a particular record in
aspnet_Membershiptable stores core data associated with every user account:
Password, the security question and answer, and so on.
If you want to use the
SqlMembershipProvidermembership provider with the default settings (meaning that the user account information will be stored in the
ASPNETDB.mdfSQL Server 2005 database in the
App_Datafolder), then you do not need to make any changes to
Web.config, other than indicating that forms authentication should be used and specifying authorization rules. (These tasks can be done for you by the Website Administration Tool, or manually. The syntax for ASP.NET version 2.0 is the same as it was in version 1.x. For more information on specifying authentication and authorization settings in
Web.configrefer to Authentication and Authorization and Authorizing Users and Roles.)
If, however, you want to use a different database, or want to change some of the membership settings (such as whether or not
email addresses must be unique, the minimum password strength, if passwords are saved as plain-text, hashed, or encrypted,
whether or not a security question and answer is required, and so on), you must specify the custom settings through a hand-entered
block of XML in the
Web.config file. (Note: you should always set a hard-coded value for the
applicationName setting. See Scott Guthrie's
set the "applicationName" property when configuring ASP.NET 2.0 Membership and other Providers blog entry for more information.)
The following chunk of XML shows how to customize the
SqlMembershipProvider settings. Specifically, this XML in bold shows the
where the settings are customized. There's also a
<connectionString> section that provides the connection string
for the database that contains the schema. (Presumably this schema was added to this database using the ASP.NET SQL Registration Tool.)
ASP.NET 2.0 includes a built-in connection string name
LocalSqlServer, which points to the
database in the
App_Data folder. If you want to keep using the default
ASPNETDB database and only
change a few properties, set the
<membership> a new provider is added named
CustomizedProvider and made the default membership
provider. This custom provider uses the
SqlMembershipProvider still, it simply customizes some of the values, setting
MyDB (as specified in the
minRequiredPasswordLength to 5, and
minRequiredNonalphanumericCharacters to 0. These are but a few of
SqlMembershipProvider settings. For a complete list see
Element for Providers for Membership.
|Always Set the |
You should never use the default Membership settings and, instead, always customize them to provide a static
|Managing Users Through the Website Administration Tool|
|Once you have configured your ASP.NET website to use the membership system, you can manage your site's users through the ASP.NET Website Administration Tool. Simply go to the Security tab and click on the "Create User" link to create a new user account or "Manage Users" link to edit or delete existing user accounts. You can also active the roles feature from the online Administration Tool, as well as assign users to roles and roles to users. The role functionality is something we will examine in future articles in this series.|
A Brief Overview of the Security Web Controls
ASP.NET 2.0 ships with all of the Web controls from version 1.x along with dozens of new ones. Of the plethora of new server controls, there are seven security Web controls. These seven controls provide a user interface for accomplishing user account-related tasks. Underneath the covers all of these controls use the membership system, meaning that even if you have a custom user store you can still use these controls if you create a custom membership provider (which will be the topic of a future article in this series!). The seven security user controls are:
- Login - presents the standard username/password login UI. By default, when the user clicks the "Login" Button a postback
ensues and the control attempts to authenticate the user's supplied credentials by calling the
VerifyUser(username, password)method. If the credentials provided are valid, an authentication ticket is created for the user, otherwise an error message is displayed in the control's interface.
To take custom steps when a user's credentials are invalid, create an event handler for the
LoginErrorevent; to implement your own authentication logic, create an event handler for the
Authenticateevent. The Login control contains a number of properties that can be configured to alter the appearance of the control's user interface. For complete control, use the
LayoutTemplate. The following screenshot shows the Login control's default UI:
- LoginView - oftentimes on a page you want to display different content dependent on whether the page is being visited
by an anonymous user or an authenticated user. For example, when an anonymous user visits the homepage you may want to show
the Login Web control. However, when an authenticated user visits the same page you want to show a message like,
"Welcome back, username," with a link to logoff.
The LoginView control allows for such functionality, containing two templates,
LoggedInTemplate. Simply place the Web controls and HTML markup you want anonymous users to see in the
AnonymousTemplateand controls and markup for authenticated users in the
LoggedInTemplate. The LoginView also provides support for displaying different output based on the logged in user's role.
- PasswordRecovery - allows a user to receive their existing password or a new password sent to them through their email address on file. If the membership provider stores the password in a hashed format, then "recovering" the password actually creates a new, random password, which is then sent to the user. For passwords store as plain-text or encrypted, the actual, existing password is emailed to the user.
- LoginStatus - this simple control displays a link to the Login page if an anonymous user is visiting the page. If an authenticated user is visiting the page, a Logoff link is shown instead.
- LoginName - this control simply displays the username of the currently logged on user. The currently logged on
user's name can also be accessed programmatically using
User.Identity.Name, just as with ASP.NET version 1.x.
- CreateUserWizard - along with a page for logging in, every user account-enabled website also needs a page
from which visitors can create a new user account. The CreateUserWizard control provides a UI for creating new user
accounts. Similar to the Login control, after the user fills in the required fields and clicks the "Create User" button the
CreateUser(...)method is invoked. The CreateUserWizard can be customized with templates, as needed. The following screenshot shows the CreateUserWizard control in action:
The CreateUserWizard control's layout and inputs can be customized; see Customizing the CreateUserWizard Control for more information.
- ChangePassword - this control allows a user to change her password.
Login.aspxand drop a Login control on the page. Voila, you have a login page without writing a single line of markup or code. If you need to customize the appearance or logic used by these controls, you have complete control. The security controls can optionally use templates, meaning that you can specify the exact markup used to render the UI. Furthermore, the security controls expose a rich event model, allowing you to tap into the programmatic processing at various points as needed. The download available at the end of this article contains pages showing how to use a number of these security Web controls; we'll examine these controls in much finer detail in future articles in this series.
|Programmatically Using the Membership System|
The membership system exposes its functionality programmatically through the |
Since many websites provide user account support, it makes sense that support for such functionality be included in ASP.NET. With ASP.NET version 1.0, the goal was only half-attained. While forms-based authentication provided a standardized means for maintaining an authentication ticket to remember a user's logged on status across web requests, it did not provide any help in storing user account information or creating the necessary web pages (login, create an account, and so on). With version 2.0, ASP.NET now provides a membership service and security Web controls that complete what was lacking in version 1.x.
In this article we looked at the goal of the membership system and one of the built-in membership providers,
SqlMembershipProvider stores user account information in a SQL Server database, and can be customized through the
Web.config file. Furthermore, we overviewed ASP.NET's security Web controls, which make implementing
login pages, create user account pages, and other user account-related user interface elements a walk in the park. Since the
security Web controls interface with the underlying membership API, and since that API is customizable thanks to being built using
the provider model, the security Web controls can be used against the
SqlMembershipProvider or your own custom
The membership system is but one part of the overall user account picture in ASP.NET 2.0. There are also roles and profile systems that allow for role-based authorization and customized user account properties without the need for writing any code or creating any additional database tables. We'll examine membership and the security Web controls in further detail, along with the roles and profile systems, in future articles in this series.
|A Multipart Series on ASP.NET's Membership, Roles, and Profile|
This article is one in a series of articles on ASP.NET's membership, roles, and profile functionality.