ASP.NET Providers - Membership, Role, and Profile

.NET, ASP.NET, ASP.NET Providers Series, IIS, Microsoft, Security, Visual Studio, Web, Windows
Comments

Seems like any website you start nowadays involves creating the same common features we see all over the web.  These include creating user account functionality, storing profile information, implementing role-based access to content and features, instantiating SQL tables and data access repositories, and so on, so forth.  In most cases it would be a complete waste of time and money to roll your own implementation every time.

There are plenty of frameworks out there that tackle this problem for you and abstract out details you shouldn’t have to worry about.  If you are in the .NET world, there are a set of these services available to you that are baked right into the .NET 2.0 Framework.  I’m going to show you a personal example of how easy it is to add some of this functionality to an existing site, even one with an antique and cumbersome architecture.  Implementing these features using the ASP.NET 2.0 Provider Model on said architecture has convinced me that it couldn’t be easier to add such functionality to a website, no matter what beast of a site you are dealing with.

ASP.NET 2.0 Provider Model

With the advent of ASP.NET 2.0, Microsoft introduced a set of configuration-driven services that adhere to the Provider Model pattern.  These services focus on storing application state of a website using a very flexible and extensible data access strategy.  The available features that can be added to your website include Membership (which includes authentication and authorization), Role Management, Profile, Session State, Web Parts Personalization, and Site Map navigation.  The whole idea is to be able to secure and enhance an existing site by dropping in a few lines into the Web.config, using a Microsoft utility to automatically create database tables (most likely your chosen storage medium), and then dropping, configuring, and skinning a few controls into your existing pages.  To read a more thorough introduction to the Provider Model and these ASP.NET 2.0 Provider services (including a few helpful diagrams), check out the following link:

Personal Example

We currently maintain a series of desktop products that we have been entrusted with.  Under the covers, these "desktop" products were originally written in Java as locally-hosted websites using Apache’s web server.  In order to be compatible with Windows Vista, we have since ported these products to .NET 2.0 and currently use UltiDev’s free, light-weight, and redistributable web server named Cassini (essentially the same thing as the development web server found in Visual Studio and a great alternative to IIS).  Many of the features are implemented in JavaScript and the content is almost entirely static HTML pages.  There were only a few Java Servlets that we ported to .NET HTTP Handlers and any database storage has been done using Microsoft Access databases.  This set of products also has other interaction requirements like the ability to view content from another product while staying in the context of the currently open product.  Finally, the installers for a few of these desktop products are getting to be nearly 600 MB in size, which has perpetuated the need for distributing the products to the users offline.

We are in the process right now of exploring the cost benefits and customer experience improvements in moving this set of offerings to an online suite of websites.  The first step we are taking is to build an online version of one of the products where users can obtain a user account to view the content.  Building new applications is one thing, but upgrading and maintaining existing applications (especially ones you have inherited) is a whole different development experience.  This is where my appreciation for the ease and flexibility of what Microsoft is offering comes into play.

Read On!

The rest of the blog posts in this series can be found at the following links:

In addition, I came across an issue when using the Profile system with the Web Application project template instead of the Web Site project template as found in Visual Studio’s default set of project templates.  It has to do with the Profile proxy class object not being auto-generated by Visual Studio when using the Web Application project template.  Read the following blog post for a discussion of the problem and it’s solution:

Also, I have another post discussing the advantages of using the ASP.NET Provider system under IIS 7 found in Windows Vista and Server 2008; it will also include some issues with using this system if some of your content is static HTML instead of ASPX pages.  You can find all of this goodness by following the link below:

Finally, I based my implementation on a 13-part tutorial series by Scott Mitchell on 4GuysFromRolla.com, starting at this link:

Enjoy!