Just a few days ago I and a colleague of mine were attempting to do just this on a production site, which collects sensitive information from users. This site used to run with SSL required globally. We wanted to allocate it only to these certain parts while understanding that the Business/UI logic shouldn’t care about the protocol it runs on. After some research, we landed on 2 solutions.
- Attribute-based approach where marking an ASP.NET page with a custom attribute would automatically redirect to HTTPS when the page is accessed over HTTP and vise-versa when going back from secure to unsecure areas.
- Configuration-based approach where secure sections of the site are defined using virtual paths & regular expressions.
The good thing is that both solutions are already out there. The first approach is detailed on CodeProject. It involves a custom attribute named RequireSSL and an HttpModule which handles redirects depending on existence of absence of the attribute on page handlers. Simply slap RequireSSL on your page class you want to protect and you’re done!
The second approach does the same thing by configuring protected paths on the site. This method does not require code changes as all configurations sit in the web configuration file. This is great for larger applications because you can protect an entire directory with a single configuration definition or if you want to go more granular you can specify a single resource or a collection of resources matching a regular expression criteria.
We went with the first approach mainly because it was much easier to setup without all 3rd party tooling and configurations and we thought it would be easier to reuse it and integrate it into our internal framework.