ASP.NET Membership Provider in the Cloud : The Chicken and the Egg Problem

Let's take a look at this pretty common scenario. You're building an ASP.NET application (MVC or otherwise) and you intend to publish it in the cloud and you're using Azure Storage (not SQL Azure) for your underlying data store. You've already hooked your app up with the sample Azure-based Membership provider that comes with the Azure SDK and everything is running along nicely.

Your application has quite a bit of administrator-only functionality so, after you've been using it locally for a while you put in some safeguards to block access to the admin areas unless the user is in the Administrators role. That's awesome and ASP.NET and ASP.NET MVC both have some really great code shortcuts for enabling this kind of situation and you can make yourself an administrator pretty darn easily.

So you're an admin and you deploy your application to staging and you go to run it and you try to log in. Whoops your account isn't there. This is because for the last couple of weeks you've been running against your local SQL 2008 (or SQL Express) database and you forgot that you did a few tweaks to make yourself an administrator. In the last couple of weeks you removed the code on the site that allows users to self-register since your application is an LOB app with a manually administered user list.

There is a built-in tool that comes with Visual Studio 2008 that allows you to do site administration. In a non-cloud environment, this was a great way to do things because you could simply configure your providers and then click "Project" and then "ASP.NET Configuration" and you would be taken to a Cassini-based website that allows you to add/remove users, manipulate roles, etc. It was great.

The problem is that when you run an Azure application locally, you're running the Role, you're not running the ASP.NET application. This means that when you launch (at least as of last night when I tried this) the ASP.NET configuration site, you're going to get a pile of errors all stemming from the fact that information contained in your service configuration file wasn't found and you'll get other errors because the local fabric doesn't get initialized when you don't start the app through the role.

So what can you do? If you can't use the admin site  then how do you create an admin user that can then create more users? Lots of really talented people have contributed to the MVC community including a fully functional admin site that uses the membership provider to administer users, etc and you can use this if you want. What I've been doing, however, to ensure that I'm never left without some form of administrative access to my sites is by creating a root account.

What I do is in the service definition I declare three settings: RootAccountName, RootAccountPassword, AdminRoleName. I then have code in my application startup that will use the Membership API to create this user with the given password and add them to the Admin Role (and create that role if it isn't created already). This guarantees me that any time I do a fresh deploy or even wipe my storage account that I'll still be able to login as an administrator to stage or production and I can keep the root account name different between stage and production.

Again, Azure development is awesome and shares a lot of similarities with traditional ASP.NET development but some things (like the built-in site admin tool) don't work out of the box via the cloud and so we have to keep these things in mind as we build applications for the cloud.

tags: aspnet  mvc  azure  cloud  membership  

links: digg this    del.icio.us    technorati    reddit