Total votes: 0
Print: Print Article
Please login to rate or to leave a comment.
Published: 11 Nov 2008
Download Sample Code
Planning to move to the Azure Cloud, but already tied to the Membership API? This article guides you to build a complete Membership provider library which can be leveraged by existing application to link to Microsoft’s cloud platform Windows Azure with no friction.
The Membership API
ASP.NET Membership API is included in .NET framework which enables you to easily integrate user registration and authentication features into your application. You can use this API with the ASP.NET Forms authentication or with the ASP.NET Login controls to create a complete system for user management.
A few of the features supported by ASP.NET Membership:
- Creating new users, password, email, question and answer
- Storing membership information in different data sources
- Manually authenticate users by code or automatically via the Login control
- Password generation, reset, retrieval
- Uniquely identifies each user record with a
Most of all, the API was designed following the Provider model which allows us to write our own data provider to support the Membership API for the particular type of data source our application will be consuming. Thus, an opportunity exists to make the same old Membership code work against Microsoft’s Azure Cloud.
The first goal is to be able to use the same old ASP.NET Login controls which enable you to quickly integrate user registration and management UI on WebForms:
Figure 1: ASP.NET Login controls
Another goal we would like to achieve with our Cloud Membership API (Cloudship) is not having to touch our existing code for storing, retrieving and managing our users. We should be able to use the same
MembershipUser classes in the same fashion. The following figure illustrates how the code should remain the same:
Figure 2: Same old Membership API
We should be able to use Cloudship with minimum addition of code. To be specific we will only reference the component as DLL (optionally you can use a project reference instead) and make few changes to the web.config of the WebRole project:
Listing 1: web.config
You will notice three unique things here – everything else are typical web.config entries. First of all we have defined
TaskTable entries in
appSettings. These values are useful for our application (AzureTodolist) which is basically what we are upgrading from the previous article on Windows Azure. I would recommend reading that article first before you continue reading this one: Building Applications for Windows Azure. We did not use the Membership API in that project. We used simple table based user management for the cloud. By the end of this article we should be able to introduce the Membership API to our Todo List. You can consider this article a sequel of the prior one.
Secondly, you will find there is no connection string defined. We do not need a connection string to be able to connect to the cloud since we will be able to connect to the cloud with the Cloud Service, which defines the
TableStorageEndpoint. Thirdly, the
providers entry has an element for
CloudshipProvider which defines its properties exactly like the
AspNetSqlProvider used in a typical project. The previous article discussed the purpose behind the
Figure 3: The Cloudship model
The CloudshipUser and the CloudshipContext
As you know from the prior article, in order to create a table in the cloud, there must be a class that defines the table structure and a context class which returns a
DataServiceQuery, so that we can run queries and insert, update, delete objects from the table and so on. The
CloudshipContext do just that. As we would like to achieve the same functionality as before - meaning that we should be able to use the
MembershipUser class - we actually cannot use that class for carrying data for our own Membership provider. The
CloudshipUser, which is almost exactly the same as
MembershipUser, looks like the one below:
Listing 2: CloudshipUser class
Notice that we did not define any
ProviderUserKey which is responsible for uniquely identifying each row in the table. Instead we used
RowKey which will act as
ProviderUserKey and will be assigned to
ProviderUserKey while converting to
RowKey is not shown above since it is inherited from
TableStorageEntity. Now that we have modeled our table, we will talk about the provider model and our implementation.
The Provider model and the CloudshipProvider
For readers who are unsure, the provider model is a pluggable architecture which can be configured via application configuration files (web.config/app.config). It allows developers to choose a specific implementation from existing libraries or build their own. There are a number of providers in addition to the
MembershipProvider. All providers inherit from
ProviderBase which has couple of properties and a virtual
Initalize method. Whenever these providers get populated into the Providers collection, each of them is provided with the corresponding configuration block in the web.config. The
MembershipProvider we usually use inherits from
ProviderBase as well.
MembershipProvider implements a bunch of abstract methods that are being used by
MembershipUser. For our
CloudshipProvider, extending from
MembershipProvider is just enough.
Figure 4: The CloudshipProvider model
As we have inherited from
MembershipProvider, now we will have to implement all the abstract methods we can find. We are going to see only a key portion of the class since it is going to be a very large one. When the provider is being added to the collection, as said before, the
Initialize method is called along with the associated configuration, passed as a
NameValueCollection instance that we need to parse in order to initialize local variables with the properties retrieved from the web.config:
Listing 3: Initialize method of CloudshipProvider
During initialization we need to make sure that the table has already been created for us in the cloud for use. If not, we create one by using the
CreateTablesFromModel method. Now the rest of the implementation is pretty self-describing and straightforward.
Implementation of CloudshipProvider.CreateUser
Listing 4: CloudshipProvider.CreateUser
Implementation of CloudshipProvider.GetUser
Listing 5: CloudshipProvider.GetUser
ConvertCloudshipUserToMembershipUser method which takes a
CloudshipUser object and returns a
MembershipUser. It performs this transformation via the code below:
Listing 6: ConvertCloudshipUserToMembershipUser
There are 22 other methods you will find in the Sample code implemented for you. You will also find a demo application which uses the Cloudship and supports the complete Membership API targeting for the cloud. For continued development stories on Cloudship, future OpenID and Windows Live ID support, you may want to keep an eye on my blog: http://www.tanzimsaqib.com/.
Compatibility and Installation
No matter which suite of controls you use: ASP.NET AJAX or MVC, Cloudship can be leveraged as your Membership provider. To install it, simply:
- Reference the DLL
- Insert few lines inside web.config
- You are good to go
In this article you learned how to implement your own Membership API, thus you can start moving you application data to the Azure Cloud – the future of development and business with Microsoft.
Please login to rate or to leave a comment.