Windows Azure "Sandbox" - asp.net-mvc-2

Question

So I have an MVC 2 App running on Windows Azure.
Everything works fine, but I want to create a subdomain where I can test some stuff that I need the actual server for, but I don't want anyone to see it. However, if I just put up like www.mywebsite.com/sandbox - anyone COULD technically access it, even though they'd have to know it's there, which I don't want.
Is there anyway I can setup something like that and password protect it or something easily? If so, I would use the same sort of thing for a private administrative URL where team members only could go in and check stuff (with a username/password that I maintain).

Answer 1

As far as I see it, you have two options available.
Create a staging deployment, and make the IIS web site respond to a specific DNS request (e.g. http://sandbox.mywebsite.nothere). Either change your DNS settings, or chane your local hosts file (e.g. in C:\Windows\System32\drivers\etc\hosts). This is security through obscurity, and while it's not effective, it's easy and perhaps a good start.
As suggested by Steve Morgan in a comment, implement authentication in your application. If you have an ASP.NET (MVC or not) application (I'm assuming MVC in my example), you can do with something like this:
Create a MembershipController
Create a Login action accepting username and password, implementation looking like this:
public virtual ActionResult Login(Qinoa.Web.Models.LoginData model)
{
if(model.Username == "myuser" && model.Password == "hardcodedPassword") {
FormsAuthentication.SetAuthCookie("myuser", model.RememberMe);
}
return RedirectToAction(MVC.Home.Index());
}
In your web.config file, set
<authentication mode="Forms">
<forms loginUrl="~/Membership/Login" timeout="2880" />
</authentication>
On all your test containers add an [Authorize] attribute. Your app is now (rudimentary) protected.
On a side note to #1: you can host multiple sites on one web role.

Answer 2

Configure your application using Windows Identity Foundation and the Access Control Service.
You then have a choice of Identity Providers that you can use to secure your application without managing your own users.
Even better, if you have Active Directory is to deploy ADFS 2.0 internally. The beauty of that is that even if someone reaches your application, they can't authenticate if they don't also have access to network on which your ADFS server runs.
I'm securing an Azure application this way and it works very well. I get transparent integrated authentication but it's highly secure.
You don't need to expose AD or ADFS outside your network to do this; there's no communication between Azure and ADFS, it's all done via the browser.