Assertion validation problems for recipient and destination urls behind a SSL terminating load balancer

[gokristian]

Situation

The assertion endpoint is behind an SSL terminating load balancer and the internal LB to server traffic is over HTTP.

The problem

Validating the SAML response URLs are done with the HTTP request's URL by default, with no way of passing an URL to the SamlResponse (which already takes a currentUrl parameter).

Proposed solution

Add validation URL protocol or full URL as an optional parameter to the processResponse method or the Auth constructor?

Workaround

Wrapping the HttpServletRequest sent to Auth, overriding getRequestURL.

[mauromol]

I've not personally experimented with this, but if you are using Spring Boot / Spring Framework, you may have a look at: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-use-behind-a-proxy-server
If I understand it correctly, the technique used by Spring Boot is exactly that, i.e. wrapping the HttpServletRequest so that the presence of the proxy is transparent to the application.

Also note that using the JK protocol instead of HTTP between the application server and the proxy will leave HTTP headers intact and won't cause this problem.

I know this is not a solution, rather just some ideas of how this problem may be approached when deploying a web application that uses java-saml. My 2 cents, though, is that IMHO it's better to abstract from the complexity of manually handling proxied URLs and then feeding them to java-saml (even if it were possible).

[gokristian]

Thanks! Saw this as well https://github.com/onelogin/java-saml#working-behind-load-balancer and will look into if it's possible to keep the URL info downstream with our setup. Also IMHO it would be nice to support a more flexible URL validation, to avoid HTTP request "hacks" or forcing to change the LB configurations. Doesn't feel too bad security wise either in comparison, but I'm no expert.

[mauromol]

Hmmm... if I'm not missing something, you shouldn't need to change the LB configuration, but rather just your application server configuration and it's not really a hack, but rather a different way to configure things so that the surrounding infrastructure configuration is transparent. I think there are other advantages coming from this, including simpler and more portable code within your application.