This post is part of a series called “Windows Azure for the ASP.NET Developer” written by Rachel Appel, Adam Hoffman (that's me), and Peter Laudati. You can see the complete list of posts in the series at the US DPE Azure Connection site.
Introduction
In the course of writing ASP.NET applications, most developers have found the need from time to time to add support to their applications for multiple users. According to Wikipedia (as of this writing), "Multi-user is a term that defines an operating system or application software that allows concurrent access by multiple users of a computer." For the purposes of a typical ASP.NET website, this roughly means that if you care to either secure your application to a particular set of people, or customize it in any way for users, then you are building a "multi-user" website. Linguistically speaking, you might think that any website that multiple users visit would qualify, but in this case, we're really talking about the need to write extra code that provides authentication, authorization, and profiling.
Let's dig into those three problem spaces a little deeper. The first two problems (authentication and authorization) tend to go hand in hand, and profiling is really complementary to these.
Authentication refers to the problem of reliably proving that someone is who they purport to be. In the "real world", it's a problem that we solve by the use of IDs, such as driver's licenses and passports. When we demand someone's identity, we expect them to produce a form of identification that is issued by a trusted authority, such as the local Department of Motor Vehicles, or a Passport Agency. We assume that if someone can produce one of these, then they are who they purport to be.
Authorization makes the assumption that a person is who they claim to be (via the Authentication services from above), but then helps to make the decision as to what rights that person has. So Authentication helps to prove that I am Adam Hoffman, but then Authorization helps to determine if I have the right to delete all of that data that I'm asking to delete.
Finally, Profiling helps to keep track of additional data that is useful for the application. Maybe your application wants to be able to say "Hello Adam" when I visit your site. My first name ("Adam") would typically be stored in some sort of profiling system, along with the other user data that was used for Authentication. Other typical types of Profiling data might include geo-location, user preferences (colors, fonts, etc.), and the like.
So, as an ASP.NET developer who is building a site that needs to support multiple logged in (and authorized) users, how should we proceed? There are basically two paths to follow, one of which has served us well for many years, and the other of which is newer, but solves a few sticky problems. These paths are the ASP.NET provider model, or Claims Based Authentication and Authorization using Windows Identity Foundation (WIF).
The Tried and True - ASP.NET Providers
Historically, ASP.NET has always provided support for these type of operations. The earliest (and still supported) version of these services were known as the Membership, Role and Profile providers, where Membership = Authentication, Role = Authorization and Profile = Profile. For an excellent introduction to the concept of Membership in ASP.NET, see http://aka.ms/ASPNETMembership . The "provider model" is a design pattern conceived by Microsoft during the 1.1 days, and formally used in ASP.NET since ASP.NET 2.0. For a description of the pattern, see http://aka.ms/ProviderModel . It allows applications to choose an implementation of functionality at runtime, from a collection of "providers" that adhere to a set of Interfaces and typically derive from an abstract base class. ASP.NET contains multiple types of providers that provide all of these services, and there are many more provided by third parties. Each of these provider types inherits from System.Configuration.Provider.ProviderBase (http://aka.ms/ProviderBase) and gets more specific from there. See the following table for details on the implementations of these services in ASP.NET.
| Provider Type | Base Class | Implementations |
| Authentication | System.Web.Security.MembershipProvider | System.Web.ClientServices.Providers.ClientFormsAuthenticationMembershipProvider System.Web.ClientServices.Providers.ClientWindowsAuthenticationMembershipProvider System.Web.Security.ActiveDirectoryMembershipProvider System.Web.Security.SqlMembershipProvider |
| Authorization | System.Web.Security.RoleProvider | System.Web.ClientServices.Providers.ClientRoleProvider System.Web.Security.AuthorizationStoreRoleProvider System.Web.Security.SqlRoleProvider System.Web.Security.WindowsTokenRoleProvider |
| Profile | System.Configuration.SettingsProvider | System.Configuration.LocalFileSettingsProvider System.Web.ClientServices.Providers.ClientSettingsProvider System.Web.Profile.ProfileProvider |
So, these are the particular implementations of the various providers that .NET provides out of the box, but you could, of course, roll your own providers if you wanted, by implementing against the abstract bases, per type. For example, to implement a perfectly valid Authentication provider, you simply need to code up something that inherits from System.Web.Security.MembershipProvider (documented at http://aka.ms/MembershipProvider ).
This is all well and good, but how would we move this technique to Azure? Well, using this technique, several different providers have already been created that do just that:
Cloudship (http://aka.ms/Cloudship) is a Membership provider that is re-implemented to use Azure Table Storage (which I discussed in my previous post in the series at http://www.stratospher.es/blog/post/windows-azure-storage-for-the-aspnet-developer ).
Similarly, the Azure Providers project on CodePlex implements Membership, Role, Profile (and Session State) providers. You can see the details of it at http://aka.ms/AzureProviders .
Additionally, Microsoft has now released (via Nuget) a set of "universal" providers for ASP.NET 4.0 and above that adds support for SQL Azure based providers. You can check that out at http://aka.ms/UniversalProviders .
So now we've looked at lots of easy ways to move to the cloud if you're already using the provider models for multi-user applications, but isn't there a different way to handle user authentication, you might ask?
As it turns out, yes. Yes there is. We’ll look at the other method in the next post, so stop back in a couple of days for that…