search

SAML-Toolkits / java-saml

Java SAML toolkit
MIT License
634 stars 398 forks source link

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

Open gokristian opened 3 years ago

gokristian commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.