I wrote a previous article that touched on some of the highlights of the new features of ASP.Net 2.0.  One of the features I mentioned is the new Membership API that Microsoft provided based on developer feedback.  Forms authentication and the new login controls provide an easy way to provide a login form and authenticate users before allowing them access to the secured areas of your web site, but this is only half the battle.  You also have to develop an administration piece that allows you to create and maintain user credentials.  This type of feature is typically needed over and over again in all the web applications that you develop and the work required to do this is tedious and redundant.  The Membership API provides the tools to alleviate the need to re-write the same code over and over again for each project.  Let’s dive in and take a closer look.

First, we will look at some of the features that the Membership API provides us.  Here is an overview of the various things that this new API provides out of the box.

1. The ability to maintain users (creating users, deleting users, etc) either programmatically or via the ASP.Net web configuration utility.
2. The ability to reset passwords easily.  You can even have an email sent to users automatically to handle the reset password request.
3. Passwords can be generated automatically if, for example, you are creating users programmatically.  These passwords can be sent to the user via email.
4. You have the ability to locate users in the user data store and create lists of users with their user details.
5. A set of controls that are provided out of the box to create login pages, registration pages, and for displaying login states for the users of your application.

The architecture of the Membership API can be divided up into four areas:

1. Security Controls – Login controls, password controls, wizard to create users, and the user status controls.
2. The Membership API itself – The Membership class and the MembershipUser class, for example.
3. Membership Providers – The base provider, SQL Server provider, Active Directory Provider, and even your own custom providers.
4. Membership Data Store – SQL Server, Active Directory, or a custom data store.

It is worth noting that the Membership API is designed to work independently of any data store.  You work with the controls and methods for accessing users, etc and the API works with a Membership Provider which implements the access to the data store of your choice.

The following is a list of the components in the Membership API:

1. Membership – this is the developer’s primary point of interaction with the API. It provides methods for managing users, validating users, resetting passwords, etc.
2. MembershipCreateUserException – The exception thrown if an error occurs while trying to create a user through the API.
3. MembershipUser – This is a class that represents a user.  It contains all the information about the user.
4. MembershipUserCollection – A collection of membership users.  The GetUsers method of the Membership class returns an instance of this collection.
5. MembershipProvider – This is the base class that you derive from if you wish to create your own provider that authenticates users against your custom data store.  You could wrap the core of your components, for example, that you have written in the past in a Provider class that descends from this class, then “plug” it in to be used as the Provider for accessing users, etc.  This is a great way to not throw away your existing code, but still take advantage of the new controls and features of the Membership API.
6. SqlMembershipProvider – A provided provider that works with Sql Server.

I would now like to go through the steps to actually using the Membership API:

First you need to configure forms authentication in your web site’s web.config file

1. Set up the membership data store (ie if you’re using SQL Server you have to create a couple of tables and stored procedures in a SQL Server database).
2. Configure the database connection string and the membership provider you want to use in the app’s web.config file.
3. Create users in your membership store in one of two ways: a) via the ASP.Net web configuration utility or develop a custom admin page which can you use the methods of the API.
4. Finally you need a login page.  You can use the login control or you can develop this yourself and use the methods of the API to validation users.

You can perform every configuration step except the provider configuration step by using the ASP.NET WAT (Web admin tool).  You access this in Visual Studio by selecting Web Site > ASP.Net Configuration.  You can use the WAT to create the data store for you if you’re using SQL 2005 on your machine or if you want to use another database, you’ll need to setup the database tables and stored procedures in advance before using the WAT.  The .NET framework ships with a tool call aspnet_regsql.exe that you can use to create the tables for you automatically.  This tool can be used via the command line or through a wizard interface and there is a lot of information on the web that can walk you through using this tool.

In ASP.Net 2.0, the web.config file has a new section called ConnectionStrings.  You will store your connection string to the data store here.  You also need to setup your provider to use so the membership API knows what provider to communicate with when you call methods such as the GetUsers method.  This is also to be done in the web.config file in a section called membership.  There are many attributes to configure here that is beyond the scope of this article, but I encourage you to search the web for the plethora of information on this topic and you’ll be set!

This concludes part one of my two part series on the Membership API.  My next article will go into more detail and give examples of using the security controls provided by ASP.Net and we will look at a complete application that uses the membership API to manage and authenticate users.

I hope this has given you a better idea of how the new Membership API can make security much simpler in 2.0.  Check back soon for Part II as we explore this neat new feature further!  Have fun!

Chad Bryant is a senior developer with The Delta Group, a Greenville, SC based firm providing web based software to the healthcare industry. In addition to programming, Chad enjoys running marathons, spending time with his wife and three daughters, and reading books. Chad can be contacted via email at chadbryant5@charter.net