Looping redirect when load balancing the web server

[GoogleCodeExporter]

Our web servers are load balanced with sticky sessions; so user is assigned to 
a server and then stays their for the duration of their session, but I believe 
ssl is only between the browser and the load balancer.  Not all is lost though 
because secured traffic travels over port 81, so I can tell if the user came in 
on a secured connection.

What steps will reproduce the problem?
1. Enable security switch and secure a page
2. View the page unsecured, client side redirect is dropped into the page.  
Page is redirected.
3. Even though the protocol is https, client side redirect is dropped into the 
page again.

What version of the product are you using? On what operating system?
Latest version, Latest windows operating system, IIS7 + integrated mode.

Please provide any additional information below.
I checked out a clone of securityswitch and was thinking I could maybe build my 
own evaluator for a load balanced environment.  

I also want to recommend adding logging for debugging.  Using an open source 
logger like NLOG, we can toggle on debugging info and the output would be good 
for ensuring things are behaving right.

I've used your code for years now and would be happy to contribute if you're 
open to it.  Can I get involved?

Thanks,

Don

Original issue reported on code.google.com by dna...@gmail.com on 15 Sep 2011 at 1:01

[GoogleCodeExporter]

Well, the good news for your situation is you can utilize the new 
EvaluateRequest event to tell the module your expected security result. You can 
evaluate the request and look for the port to tell the module how to respond 
(e.g., Secure, Insecure, or Ignore).

Here is the latest documentation on providing an event handler:
http://code.google.com/p/securityswitch/wiki/DynamicEvaluation

Please, let me know if the event handler route works for your situation. I'd 
also love to get a real-world sample of its use for something like this to put 
on the wiki.

I've been wanting to add logging for a while now too. My first concern was how 
to handle logging with requiring a dependency on a particular logging library. 
If I depend on NLog and somebody is already using Log4Net, they have to 
configure another logging engine just to support my dependency. Lately, I've 
been considering the use of the Common.Logging library to overcome this very 
issue.
http://netcommon.sourceforge.net/

This way, this project puts a dependency on Common.Logging only and the users 
of the module decide which implementation to use for their project (i.e., 
Common.Logging.NLog vs. Common.Logging.Log4Net). That may just be the next step 
for this project. Thoughts?

I'd be glad to take pull requests from clones. After we develop a relationship, 
I'd certainly be open to adding you as a direct contributor to this project. 
:-) I'm glad you've been able to use this module (in one version or another) 
with success over the years.

Original comment by vent...@gmail.com on 15 Sep 2011 at 9:03

[GoogleCodeExporter]

Thanks for the suggestion.  Let me know if I'm not understanding correctly, but 
with the EvaluateRequest event I would have to code into the global.ascx.cs, 
which files / directories I wanted to secure. We are hosting a number of sites 
and need to be able to adjust the rules easily, so we would like to continue to 
use the web.config for storing path rules.  

Your code is fantastic and I'd still love to contribute, but leave it up to 
you.  I believe it's very common with a load balancing infrastructure that the 
ssl certificate is registered on the load balancer.  Then all forwarded traffic 
is sent to the web server on a non-standard port over http.

Load Balancer (ssl) -> web server (non-secured always)

In this instance your evaluator which is running on the web server will always 
think the connection is insecure, even though the user came in over https but 
only up to where the load balancer forwarded them.  I even noticed a few posts 
about it on sourceforge.  You've structured your code really well, so it's easy 
to create another evaluator for this architecture.  

What would be perfect is a option in the web.config that tells securityswitch 
to detect secured connection strictly by port and use the Request.Url.Port to 
evaluate.  Another option would be an event that I could use like the 
EvaluateRequest, but just overrides evaluating if a connection is or isn't 
secured already... maybe EvaluatorEvent with an arg e.IsSecure that you set to 
true or false.  

I also had to adjust the redirect logic since it was picking up the 
non-standard port the web server was using and putting into the targetURl... I 
trimmed the port off, because from the client / loadbalancer point of view it 
wasn't important to have in the url and in fact stopped the redirect from 
working.  ANother web.config option maybe (exclude port number in redirects)

I know this problable sounds weird, because I noticed your secured connection 
evaluator is very robust, but this is how you have to do it for load balanced 
environments that don't purchase 3 certs (one for load balancer and two for the 
web servers). Still securityswitch has a number of other features that make it 
better than a roll-your-own. For example the suppression of browser warnings 
and allow us to store security rules in web.config files.

Again fantastic code and thanks for letting me use it over the years. Let me 
know if you want help adjusting the code for this (although I bet you get how I 
did it).

Thanks,

Don

Original comment by dna...@gmail.com on 16 Sep 2011 at 9:53

[GoogleCodeExporter]

Hi,

Most of the load balancers I've dealt with set a request header to indicate 
whether or not the request is secure or not (e.g., SSL=[on|off]). The module 
does support such a common scenario. Take a look at the 
offloadedSecurityHeaders configuration attribute on that wiki page. Perhaps 
your load balancer sets a header in addition to port transformation.
http://code.google.com/p/securityswitch/wiki/SecuritySwitchConfigSection

If that's a no-go, I would definitely see the benefit of expanding the 
EvaluateRequest event so you could instruct the module to continue to evaluate 
what should be secured, but that you would determine if the request is already 
secure or not. It would add an extra bit of customization without the 
all-or-nothing mantra.

In addition, if port detection for security is the most common of these 
scenarios, a config option to check the port sounds good too.

As for stripping the port number, you could set baseInsecureUri and 
baseSecureUri to get around that problem. Just set them both to your FQDN 
without the port:
<securitySwitch ... baseInsecureUri="http://www.mysite.com" 
baseSecureUri="https://www.mysite.com">...

That will force the module to use those values for redirection as opposed to 
looking just at the current request.

Please, let me know if the existing features support your scenario. Otherwise, 
I'm very interested in improving the module. Thanks!

Original comment by vent...@gmail.com on 19 Sep 2011 at 1:43

[GoogleCodeExporter]

I finally got around to adding this feature! With the latest build, you can 
specify the new securityPort configuration attribute. In your example, you 
would set it to 81 and the module should pick up secure connections properly.

<securitySwitch baseInsecureUri="http://www.mysite.com" 
baseSecureUri="https://www.mysite.com" securityPort="81">...

I'm also looking into adding logging next and will make a new issue just for 
that.

Thanks for your input!

Original comment by vent...@gmail.com on 5 Nov 2011 at 6:49

• Changed state: Fixed