Provider Architecture

Instead of hardwiring these controls to talk directly to the membership database, the ASP.NET team decided to introduce a provider model to abstract the data source from the controls that use it. You'll find this model in a lot of different places in ASP.NET,^[5] but to make things more concrete, Figure 5-5 illustrates how the Membership provider works.

^[5] Check out the list of classes that derive from System.Configuration.Provider.ProviderBase if you're interested in finding other places where this pattern is used. The MSDN documentation for the class is a great way to do this.

Figure 5-5. Provider architecture

This model is common in software design. It decouples the consumer of a service from the implementation of that service, or as the ASP.NET team refers to it, the provider of the service. In this case, we're talking about user accounts, or membership. ASP.NET includes an abstract base class, MembershipProvider, from which all concrete implementations must derive in order to plug into this architecture. The default Membership provider is SqlMembershipProvider, which sits on top of a SQL Server database. ASP.NET also ships with an Active Directory (AD) provider, which can be configured to use an Active Directory domain or an Active Directory Application Mode (ADAM) instance as the source of user accounts. You can also create your own implementation by deriving a class from MembershipProvider. The feature set you get will differ slightly across providers, and we will point out many of the differences in this chapter.

The ASP.NET infrastructure (such as the membership controls and the administration Web application) knows how to use the MembershipProvider base class, but doesn't care about the details of how it's implemented, which makes it much easier to swap out different stores for your user accounts. For example, you might choose to use the AD provider if you must use a forms-based login but want users to be authenticated against accounts in Active Directory. This would make sense for an Intranet application designed for use with browsers that don't support integrated authentication, where you are forced to use a forms-based login. Another instance in which pluggable providers are useful is when you have an existing user store that isn't supported by ASP.NET out of the box. You can write your own provider in this case, as many people already have.^[6]

^[6] As of this writing, a quick search reveals a MySql provider (at http://codeproject.com), a web.config provider (search for "WebConfigMembershipProvider" at http://leastprivilege.com), a Web service-based provider (search for "MembershipProvider and Web Services" at http://codeproject.com), among others. These are only referenced as examples and have not been tested by, nor are they endorsed by, the authors.

Another nice benefit of this model is that you can write your own code that uses the Membership provider. We've included a tool called the ASP.NET Administration Console as an example with this book that does just this. You will find this code helpful in learning more about how the Membership and Role providers work. Besides finding it a helpful learning tool, you'll probably find that it performs better than the built-in Web administration application that comes with Visual Studio.