Wed, 03 Nov 2010 00:00:00 GMT
Membership, in a nutshell, is a framework build into the .NET Framework that supports creating, authenticating, deleting, and modifying user account information. Each user account has a set of core properties: username, password, email, a security question and answer, whether or not the account has been approved, whether or not the user is locked out of the system, and so on. These user-specific properties are certainly helpful, but they're hardly exhaustive - it's not uncommon for an application to need to track additional user-specific properties. For example, an online messageboard site might want to also also associate a signature, homepage URL, and IM address with each user account.
There are two ways to associate additional information with user accounts when using the Membership model. The first - which affords the greatest flexibility, but
requires the most upfront effort - is to create a custom data store for this information. If you are using the
SqlMembershipProvider, this would mean
creating an additional database table that had as a primary key the UserId value from the
aspnet_Users table and columns for each of the additional user
properties. The second option is to use the Profile system, which allows additional user-specific
properties to be defined in a configuration file. (See Part 6 for an in-depth look at the Profile
This article explores how to store additional user information in a separate database table. We'll see how to allow a signed in user to update these additional user-specific
properties and how to create a page to display information about a selected user. What's more, we'll look at using ASP.NET
Routing to display user information using an SEO-friendly, human-readable URL like
www.yoursite.com/Users/username. Read on to learn more!
Wed, 04 Nov 2009 00:00:00 GMT
Many of the web applications I help build can be classified as in-production line of business applications that receive frequent and ongoing feature enhancements. Typically, these applications have dozens if not hundreds of users who rely on the site each and every day to accomplish tasks necessary to keep the company running smoothly. Every week or so the latest code is deployed to the production servers, bringing with it bug fixes and, very often, new features or changes to existing features. One challenge I've bumped into when working on such applications is how to best alert users of the new features and the changes to existing features?
One useful way to announce any important, system-wide changes is to do so immediately after the user signs into the site. A very simple way to accomplish this would be to automatically redirect all users to an announcements page after signing in, which would list information about the most recent updates to the application. However, this approach desensitizes the user to the announcement page since they are sent there each time they sign in, regardless of whether they've already seen the announcement. A better approach is to determine if there were any announcements made since the user last signed in. If so, redirect the user to a web page that displays just those unread announcements.
This article shows how to implement such a system using ASP.NET's Membership system, the Login control, and a dash of code. A complete working demo is available for download at the end of this article. Read on to learn more!
Wed, 08 Jul 2009 00:00:00 GMT
Expiring passwords are a common technique used for improving the security of a computer system. In a nutshell, the system specifies a number of days for which a given password is valid, be it 30 days, 90 days, 120 days, or longer. Once this validity window passes, a user must change her password to a new one before being able to log in. Operating systems like Microsoft Windows have long provided such functionality, but password expiry is a feature that is not as prevalent in web applications.
The ASP.NET Membership system and Login Web controls do not offer out of the box support for password expiry. However, all of the pieces are there for us to implement password expiry; it takes just a dash of markup here and a pinch of code there. For example, the Login Web controls include a ChangePassword control, which allows a user to reset his password. The Membership system already tracks the last date and time a user changed his password, and with a few lines of code we can customize the authentication logic for the Login control, prohibiting users whose password has expired from logging in.
This article shows how to implement password expiry in an ASP.NET application that uses the
SqlMembershipProvider Membership provider; the complete code
is available for download at the end of this article. Read on to learn more!
Wed, 01 Jul 2009 00:00:00 GMT
When a visitor registers a new account on an ASP.NET website that uses the Membership system, they are prompted (by default) for their username, password, e-mail address, and other pertinent information. Along with functionality for registering new accounts, the ASP.NET Membership system provides page developers techniques for modifying information about users. For instance, with just a couple of lines of code you can change an existing user's e-mail address, approve a user, or unlock them (if their account was locked out). However, there are certain bits of user information that cannot be modified through the Membership API, such as the username.
for most sites this is a non-issue. Once a visitor has registered an account that username is fixed; if they want a different username, well, they'll just have to register a new account. But consider a website that has customized the account creation process so that instead of prompting the user for both a username and e-mail address, the user is only asked to enter an e-mail address and that it is used as both their username and e-mail address on file. Anytime a user switched e-mail addresses - which can happen when changing jobs, changing ISPs, or moving to the new, hip, web-based e-mail provider of the day - they need to also change their username on your site.
In order to change a user's username we'll need to bypass the Membership API and work directly with the user store. This article shows how to interface directly with the
SQL Server database schema used by the
SqlMembershipProvider to change an existing user's username. Read on to learn more!
Wed, 20 May 2009 00:00:00 GMT
The ASP.NET Toolbox includes two Web controls for managing users' passwords: the ChangePassword control and the PasswordRecovery control. The ChangePassword control allows a user signed into the site to change their password by entering their existing password and their new, desired password. The PasswordRecovery control is used to reset or recover a user's password in the event that it has been forgotten. The PasswordRecovery control is used by anonymous users who need to be reminded of their password. Assuming that the Membership system is configured to require that users have a security question and answer (the default behavior), the user is presented with their security question and must correctly enter their security answer in order to have their password reset or recovered.
While there are two controls for managing passwords, there are no Web controls in the Toolbox for managing a user's security question and answer. In other words, there's no
built-in control that allows a signed in user to change her security question and answer. The good news is that while no control offers this functionality it's not difficult
to implement this feature ourselves. The
MembershipUser class has a
that modifies the security question and answer information using the configured Membership provider.
This article shows how to build a page that permits a signed in user to change their security question and answer, and a demo application is available for download at the end of the article that showcases this functionality in action. Read on to learn more!
Wed, 22 Oct 2008 00:00:00 GMT
ASP.NET's forms-based authentication system in tandem with the Membership API and Login Web controls make it a cinch to create a user store, create user accounts, and allow visitors to log into the site. What's more, with little effort it's possible to define roles, associate user accounts with roles, and determine what functionality is available based on the currently logged in user's role (see Part 2). Many ASP.NET sites that use Membership have an Admin role, and users in that role are granted certain functionality not available to non-Admin users. Consider an online store - Admin users might be able to manage inventory, whereas the only way normal members could interact with the inventory was by adding items to their shopping cart.
I was recently working with a client who had an interesting request: he needed the ability for Admin users to be able to log into the site as another user, and perform actions as if that other person had logged in herself. Returning to the online store example, imagine that some customers periodically phone in their order, or mail or fax in an order form. An Admin, receiving this order, could then log into the site as that customer and place the order on the customer's behalf.
This article shows how to allow an Admin user to log into a Membership-based website as another user, and includes a complete working demo available for download at the end of the article. Read on to learn more!
Wed, 23 Jul 2008 00:00:00 GMT
Several of the earlier installments in this article series examined how to apply authorization rules in order to prohibit particular users, roles,
or classes of users from accessing particular resources. For instance, Part 2
showed how to define URL-based authorization rules in
web.config for roles. With just a bit of XML markup, it is possible to block particular users
or roles from visiting certain web pages. Just installments also looked at using the LoginView control, which displays different markup based on whether
the user is authenticated or not (and can also be used to display different markup based on the currently logged in user's role).
There are also programmatic techniques you can use to determine the identity of the currently logged on user and what roles she belongs to.
The URL-based authorization, LoginView control, and programmatic techniques can be used in tandem to ensure that a user does not visit a page or
perform some operation if she is not authorized. But what if you forget to implement one of these safeguards? For example, imagine that you have a web
page that includes a button that, when clicked, perform some task that is only intended for administrators. You could put this button in a LoginView
control or you could use programmatic techniques to ensure that only users in the appropriate role (say,
Admin) saw the button. But what if
sometime later you, or another developer, removed this check by accident? The net result would be that any user visiting the page could perform the
administrator-only operation! Whoops!
To reduce the likelihood of such security mishaps, the .NET Framework includes capabilities for declaratively asserting permissions (via attributes) on methods and classes. In a nutshell, you can add such attributes to ASP.NET pages, their code-behind classes, and your business logic and data access layers. With these attributes in place, your visitors will be barred from performing unauthorized actions, regardless of whether there are any security holes in the user interface. Read on to learn more!
Wed, 25 Jun 2008 00:00:00 GMT
Many websites that support user account allow anyone to create a new account, but require new users to undergo some form of verification before their account is activated. A common approach is to send an email to the newly created user with a link that, when visited, activates their account. This approach ensures that the email address entered by the user is valid (since it is sent to that user's email address). This workflow not only ensures the valid data entry, but also helps deter automated spam bots and abusive users.
In past installments of this article series we've seen how to use the CreateUserWizard control to allow users to create new accounts. By default, the user accounts created by the CreateUserWizard control are activated; new users can login immediately and start interacting with the site. This default behavior can be customized, however, so that new accounts are disabled. A disabled user cannot log into the site; therefore, there needs to be some manner by which a newly created user can have her account enabled.
There are many ways by which an account may be activated. You could have each account manually verified by an administrative user. If your site requires users to pay some sort of monthly fee or annual due, you could have the account approved once the payment was successfully processed. As aforementioned, one very common approach is to require the user to visit a link sent to the email address they entered when logging on. This article explores this latter technique. Read on to learn more!
Wed, 16 Apr 2008 00:00:00 GMT
The Membership system automatically tracks the last
date and time each user's account has been accessed. With the
SqlMembershipProvider, this information is
stored in the
aspnet_Users database table in a
datetime column named
column is automatically updated to the current UTC date and time whenever a user
logs into the site, whenever their user account information is updated, and whenever their user account information is retrieved.
In addition to tracking each user's last activity date and time, the Membership system includes a method named
This method returns the number of users whose last activity date and time is within a specified window; by default, this method returns the number of
aspnet_Users.LastActivityDate value falls within the last 15 minutes.
This article, the tenth installment of a multipart article series on ASP.NET's Membership, Roles, and Profile systems, examines
GetNumberOfUsersOnline method and see how to extend the Membership system to include additional user
activity information. Specifically, we will add a new table to the database used by the
SqlMembershipProvider that associates a description
of each user's current action. We will then update our ASP.NET pages to update the records in this table to include a description of the user's
current action. For example, when visiting the home page we may use the description, "Viewing the home page." Finally, we will create a web page that displays
the list of currently logged on users and their last known action. Read on to learn more!
Wed, 12 Sep 2007 00:00:00 GMT
ASP.NET's Membership, Roles, and Profile systems were designed using the provider model, which
enables these systems to seamlessly use different implementations. ASP.NET ships with a provider for managing members and roles through SQL Server and another for using
Active Directory. It is also possible to plug in other implementations that have been built from the ground up or downloaded from other sources. For example, you can download
alternative providers from Microsoft that store membership and role information in a Microsoft Access database (see
Part 8 of this article series). Most of the articles in this series, however, have focused on using the
SQL Server provider (
SqlProfileProvider). The SQL Server providers are typically
the provider of choice for Internet-based web applications, whereas the Active Directory providers are more commonly used in intranet scenarios.
The SQL Server providers create a number of tables, views, and stored procedures in the specified SQL Server database. Therefore when using these providers it is possible to add, modify, or delete membership or roles or profile-related data through T-SQL statements. In this article we'll look at a common membership need - deleting users. While users can certainly be deleted through the .NET Membership API, there are scenarios where it may be much easier to use a T-SQL script. However, bypassing the managed APIs and working directly with the database is not without its own host of challenges. By the end of this article we'll have addressed these issues, discussed the pros and cons of using T-SQL in lieu of the managed APIs, and have examined both the managed API methods and T-SQL commands for deleting a single user and deleting all users. Read on to learn more!
Wed, 03 Jan 2007 00:00:00 GMT
One of the main challenges of building a programming framework is balancing the desires to create a standardized, straightforward API for accomplishing common tasks and providing flexibility and customizability so that developers using the framework can mold the framework to fit their applications rather than having to bend their applications to fit the framework. With the .NET Framework, Microsoft implemented this delicate balance with the provider model. The provider model allows for a standardized API to be defined within the framework, but enables developers to design their own concrete implementation and plug that implementation into their systems at runtime. In Part 7 of this article series we saw how the Membership, Roles, and Provider pieces examined throughout this series all utilize the provider model. Moreover, in Part 7 we created a custom XML provider for the Profile system.
I recently worked on a website that primarily contained static content. The client, however, had a particular page that needed to display data from a simple database with just one table. Additionally, a web page was needed to allow a set of administrators to add, update, and delete data from this table. With ASP.NET's data source controls and Membership system, this functionality is typically a breeze, but there was a catch - the web hosting company didn't support SQL Server databases, so Microsoft Access databases needed to be used instead. The challenge here is that the .NET Framework BCL only contains a Membership provider for Microsoft SQL Server.
Fortunately, Microsoft provides an Access database template and providers for using Membership, Roles, and Profile with Access. In this article, we'll look at how to get these Access-based providers and how to use the provider in an ASP.NET web application. Read on to learn more!
Wed, 18 Oct 2006 00:00:00 GMT
One of the main challenges of building a programming framework is balancing the desires to create a standardized, straightforward API for accomplishing common tasks and providing flexibility and customizability so that developers using the framework can mold the framework to fit their applications rather than having to bend their applications to fit the framework. With the .NET Framework 2.0, Microsoft implemented this delicate balance with the provider model. The provider model allows for a standardized API to be defined within the framework, but enables developers to design their own concrete implementation and plug that implementation into their systems at runtime. (See A Look at ASP.NET's Provider Model for more details on the provider model, its implementation in ASP.NET 2.0, and the concepts behind it.)
The Membership, Roles, and Provider pieces examined throughout this article series all utilize the provider model. Throughout the past
six installments of this article series we've examined some of the providers that ship with the .NET Framework (such as
SqlProfileProvider). In fact, you can
download the source code for these built-in providers from Microsoft as well as a Provider Toolkit for creating your own
custom providers [link]. And Scott
Guthrie lists a number of custom Membership, Roles, and Profile providers in his ASP.NET
2.0 Membership, Roles, Forms Authentication, and Security Resources page.
If the none of the built-in providers meet your needs, you can always create your own custom providers. Custom providers are
useful when integrating legacy systems (perhaps you have an old
Users database table that differs from the
database tables used by
SqlMembershipProvider) or when needing to persist membership, role, or provider information
in a backing store not natively supported by one of the built-in providers.
In this article, we'll discuss the concepts behind creating and using a custom provider and then implement a simple custom profile provider that serializes profile information to XML files. Read on to learn more!
Wed, 11 Oct 2006 00:00:00 GMT
The Membership API in the .NET Framework provides the concept of a user account and associates with it core properties: username, passsword, email, security question and answer, whether or not the account has been approved, whether or not the user is locked out of the system, and so on. However, depending on the application's needs, chances are your application needs to store additional, user-specific fields. For example, an online messageboard site might want to also allow users to specify a signature, their homepage URL, and their IM address.
There are two ways to associate additional information with user accounts when using the Membership model. The first - which
affords the greatest flexibility, but requires the most upfront effort - is to create a custom data store for this information.
If you are using the SqlMembershipProvider, this would mean creating an additional database table that had as a primary key
UserId value from the
aspnet_Users table and columns for each of the additional user properties.
In the online messageboard example, the table might be called
forums_UserProfile and have columns like
UserId (a primary key and a foreign key back to
Rather than using custom data stores, the ASP.NET Profile system can be used to store user-specific information.
The Profile system allows the page developer to define the properties she wants to associate with each user. Once defined,
the developer can programmatically read from and assign values to these properties. The Profile system accesses or writes
the property values to a backing store as needed. Like Membership and Roles, the Profile system is based on the
provider model, and the particular Profile provider
is responsible for serializing and deserializing the property values to some data store. The .NET Framework ships with
class by default, which uses a SQL Server database table (
aspnet_Profile) as its backing store.
In this article we will examine the Profile system - how to define the user-specific properties and interact with them
programmatically from an ASP.NET page - as well as look at using the
SqlProfileProvider that ships with
.NET 2.0. In a future article we'll look at how to create and use a custom profile provider. Read on to learn more!
Wed, 07 Jun 2006 00:00:00 GMT
ASP.NET 2.0 makes it quite easy to accomplish common tasks. Want to display data from a database, allowing the user to sort, edit, delete, and page through that data? Simply add and configure a SqlDataSource on the page, bind it to a GridView, check a few checkboxes in the GridView's smart tag, and, voila, you have a web-based data entry form that can be created in 15 minutes or so. While the simple case is often a cinch to implement, in the real world rarely is the simple case a practical solution. Often, the simple case needs to be extended and expanded and customized to fit custom rules, logic, formatting, and behavior. Thankfully, ASP.NET 2.0 was designed with extensibility in mind and, thanks to things like the provider model, event handlers, and templates, customizing and extending the simple case is both doable and usually doable without an inordinate amount of effort or "hackery."
As we've seen throughout this article series, ASP.NET provides a platform for creating and managing user accounts through its membership, roles, and profile systems. The related Web controls - Login, LoginView, CreateUserWizard, LoginStatus, and so on - can be used to achieve the simple case. Need to provide an interface for logging on a user? Simply drop the Login Web control onto a page. But what if we want to customize the login experience? We may want to reposition the Web controls used by the Login control or add additional content or Web controls to the Login control interface. Or we may want to customize the credentials supplied by the user for authentication purposes. Rather than requiring just their username and password, what if we want to also make them supply their email address on file? Or perhaps we want to include a CAPTCHA (those boxes with text in an image designed to defeat robot programs from successfully submitting a form).
The Login Web control can be customized in a number of ways. First, it has a bevy of properties that can adjust whether
or not the "Remember me next time" checkbox is displayed, the text displayed for the "Log In" Button, the colors, fonts, and
other style-related settings, and so on. For further control over the layout of the Login control or of the actual controls
that makeup the Login control, we can convert the control into a template. And finally, the control's authentication logic can
be customized by creating an event handler for the
(which can allow us, for example, to use a CAPTCHA as part of the authentication process).
In this article we'll examine how to customize the Login control through its properties, through templates, and by performing
custom authentication through an
Authentication event handler (including an example with a CAPTCHA). Read on to learn more!
Wed, 03 May 2006 00:00:00 GMT
ValidateUser(userName, password) method
that returns a Boolean value indicating whether or not a user's supplied credentials are valid. This method is automatically utilized
from the Login Web control and
can also be used programmatically, if needed. In the Membership system, there are multiple scenarios by which a user's credentials
can be invalid:
ValidateUser(userName, password) method just returns False if the credentials
are invalid, and does not include information as to why, exactly, the credentials are invalid. For the Login control, when
ValidateUser(userName, password) returns False the message, "Your login attempt was not successful. Please try again."
is displayed, by default. If a user is locked out or their account not yet approved, such a message - which will be shown even in
the face of the correct username and password - can easily lead to a confused and frustrated user.
In this article we'll see how to provide additional feedback during the login process to help alleviate any such confusion.
Moreover, we'll see how to audit invalid logins and present the data in a report. Read on to learn more!
Read More >
Wed, 05 Apr 2006 00:00:00 GMT
The membership and roles providers used by ASP.NET by default are the
respectively, which serialize membership and roles information to a SQL Server database. Specifically, this information is stored
in a variety of pre-defined tables and accessed through a number of pre-defined stored
procedures. In order to use membership or roles with your application using the default providers you need to apply this
pre-defined schema to your application's database.
If you don't already have a database, ASP.NET will happily create a SQL Server 2005 Express Edition database in your application's
App_Data folder that contains the necessary schema. While this is certainly handy, often developers are faced with
a situation where they want to add ASP.NET's membership and roles features to an existing data model. For example, you may
have an application that hasn't yet needed membership or roles services, but recent feature requests may require that certain
areas of the site are available only to particular users, or certain functionality is limited to those who belong to a specific
role. In any case, adding membership and roles support to an existing database can be accomplished through the
ASP.NET SQL Server Registration Tool (
In this article we'll examine how to use this tool to apply the membership and roles services for the
providers. This tool can be used both from the command-line and through the graphical wizard. Furthermore, we'll pay special attention
on how to use this tool with an existing SQL Server 2005 Express Edition database in the
App_Data folder, which
can be a particularly challenging task. Read on to learn more!
Read More >
Wed, 14 Dec 2005 00:00:00 GMT
In Part 1 of this article series we saw how
ASP.NET's membership service provides a framework for managing user accounts. The framework is composed of a
Membership class with a bevy of methods that can be used to create, delete, modify, retrieve, and authenticate
users. Since every developer's needs are different, a concrete membership framework would be virtually useless except for
new, simple projects. Thankfully the
Membership class is designed using the provider model, meaning
that the membership framework's actual implementation can be customized. ASP.NET ships with two membership providers -
ActiveDirectoryMembershipProvider - and you can build your own, if needed.
Many websites that provide user accounts need to group users in various roles. The roles a user belongs might specify what web pages they have access to, what information they see on the screen, and whether or not certain regions in a page are editable or view-only. Grouping users into roles and basing functionality and authorization based on a user's role is quite easy in ASP.NET thanks to the roles service. Like the membership service, the roles service defines a framework for programmatically creating and deleting roles, assigning and removing roles from users, and determining what users belong to a role, and to what roles a user belongs.
In this article we will examine ASP.NET's role service. We'll start by seeing how to setup and configure the roles service
on a website, along with how to base authorization rules using roles. In addition, we'll look at how to programmatically
work with the roles service, and see how to use the LoginView Web control to show information based on the logged in user's role.
Read on to learn more!
Read More >
Wed, 07 Dec 2005 00:00:00 GMT
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!
Read More >