Restricting a public-facing demo site for an asp.net application? - asp.net

Question

I'm convinced there has to be a dupe of this somewhere, but I couldn't find it easily:
Given an asp.net application that in itself uses Forms Authentication, what is the best practice for securing a public-facing demo site such that nobody who is not in the "in crowd" can see the site at all?
IP Filtering?
Basic auth wrapped around the forms auth? I've banged my head on this one and can't seem to make it work :/
VPN?
"making a demo site public facing considered harmful" in the first place?

Answer 1

Have you considered leveraging your Web.Config?
For areas that you want anonymous access use:
<location path="unsecured_path">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Or to deny anonymous users
<location path="secured_path">
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</location>
If you deny anonymous users, you will need a way to authenticate your users. Either by Windows security which will give a challenge response when you try hitting it anonymously, or by giving the user a pretty log in page.

Answer 2

Typically the "demo sites" are secured with Basic Authentication. e.g. return a 401 to the browser with a basic authentication challenge that it turns into prompting for credentials. In theory, once this is done, the rest of the site is just regular stuff -- forms auth when needed.
The difficulty with this approach in ASP.NET comes in the fact that the default FormsAuthenticationProvider is hard-wired to interpret a 401 as "need to 302 to the login page." With that as a premise, getting both Forms Authentication and Basic Authentication to happen simultaneously is a challenge.
Also, the Basic Authentication built-in to IIS uses Windows as the authentication store (Active Directory or local windows accounts.) Getting it to use a different credential store is not easy to do "in the box".
http://custombasicauth.codeplex.com/ is a project I've been watching that is quite intriguing. It provides a custom Basic Authentication provider that allows you to rig up Basic Authentication from a different provider store. Pop open the source to http://custombasicauth.codeplex.com/SourceControl/changeset/view/53965#183990 and http://custombasicauth.codeplex.com/SourceControl/changeset/view/53965#183995 and see that they're just extracting the Base64-encoded header, and comparing it to an ASP.NET Membership Provider. With that as a premise, you could rig up a similar HttpModule to compare the header data to a user/pass stored in AppSettings, and include the module in your demo site. The magic sauce is that you don't set the 401 status on Authenticate, you do so at EndRequest -- after the FormsAuthenticationModule has finished it's "401 to 302 to login page". The only down-side is the <location> tags have to be used by Forms Auth or by Basic Auth, but not both. If the use-case is truely "secure the entire demo site", then it's sufficient to code the Basic Auth module to "just do it all". I'm about 2/3 of the way doing exactly this. When I'm done, I'll likely post it to GitHub as it's turning out pretty cool. Alas, the technique isn't that hard, and perhaps the description of the solution is sufficient.
And if you really want a hands-off, no-code solution, install http://custombasicauth.codeplex.com/. It even gives you pretty config windows in IIS. :D

Answer 3

You might want to try using a different port other than 80 for the site. It's not the most secure thing in the world if you really don't want people to know about it, but it is definitely security via obscurity. It doesn't prevent you from using your forms authentication, but you will probably need a little extra configuration to transition between http and https traffic neatly.
So if your site is http://test.org and you also set up your demo site to be http://test.org:9666, any regular traffic to the site will hit the non-demo site. That may not be clear, but I hope it gets the idea across meaningfully.

Answer 4

You can filter by IP - I have done this before in a backend admin system. This worked fine in my case as the only users had static IPs but most people I would expect don't have this so you will constantly have to keep tweaking to allow access.
Using some settings in IIS you can add an additional level of authorisation (you will have to Google how to do this) - users will then need to login once to view the site and again on the login screen.
You hit the nail on the head here - if you don't want people to see it, don't put it on the Internet.
Based on the above my answer would be either do nothing and rely on your login system for this (after all the only thing public is the login page) or do not make it public - use some sort of VPN.

Answer 5

If you're familiar w/ Apache .htacces and .htpasswd configuration take a look at http://www.helicontech.com/ape/ (Free up to 3 sites). Helicon Ape is an IIS plugin that implements htacess/htpasswd features.
Very simple password mechanism. '.htpasswd' lets control access by creating a simple text file w/ username:md5 password hashes. You can either MD5 the passwords yourself or use an online site like http://aspirine.org/htpasswd_en.html to generate. Example:
apple:$apr1$4SZNOvdK$P7b6AkKVw.gXfdxlcvENp1
orange:$apr1$fvcwHIlc$OF7Mkhv8JfELDJnRmsku7/
banana:$apr1$IoSJc9GM$xtSY4nI3KCnTtjWKwxhmx/
User/pass to gain access is:
apple:sauce
orange:juice
banana:split