Advanced Tweak on Undertow-handlers.conf for http https redirect - wildfly

I use WildFly behind an AWS load balancer. I want the Undertow server in WildFly to redirect http traffic to https, and I can do this mostly successfully with the following line placed in undertow-handlers.conf:
equals('http', %{i,X-Forwarded-Proto}) -> redirect(https://app.server.com%U)
Thanks to these folks for getting me this far! Now here's my desired tweak. Sometimes I run my web application behind a testing load balancer using 'dev.server.com' and sometimes I run it behind a production load balancer using 'app.server.com.' Currently, I have to remember to manually edit undertow-handlers.conf any time I switch balancers. I'm hoping there is a way to change the hard-coded 'dev' and 'app' to something mechanical. Is there a way to tell Undertow to just use the domain name that was originally requested?
Thanks.

Thankfully the undertow configuration gives you access to the request headers via Exchange Attributes, which you're already using to access the X-Forwarded-Proto header. So the solution is to simply use the Host header from the request like so:
equals('http', %{i,X-Forwarded-Proto}) -> redirect(https://%{i,Host}%U)

If you want to keep it as part of the deployment try using the %h in the redirect expressions. For example:
equals('http', %{i,X-Forwarded-Proto}) -> redirect(https://%h%U)
Another option would be to configure the server to handle the redirect for you. The CLI commands would look something like the following assuming the default ports of 8080 for http and 8443 for https.
/subsystem=undertow/configuration=filter/rewrite=http-to-https:add(redirect=true, target="https://%h:8443%U")
/subsystem=undertow/server=default-server/host=default-host/filter-ref=http-to-https:add(predicate="equals(%p, 8080)")
You can see all the possible exchange attributes in the Undertow documentation.

Related

Wildfly HTTP-only redirect

Quick and dirty fix needed here if possible...
We've been running a bunch of REST services on a Wildfly installation for a few years. The server isn't for public use -- on the main https://ourserver.com page we have a redirect which points wandering users to our main website. It's a very simple standalone config.
But the server has always been HTTPS only. And now thanks to a domain reshuffle, we need to make it possible for users who go to http://ourserver.com without SSL to hit the redirect to ourserver.net. So we basically need to expose just the welcome-content directory on this server over the "http" interface (which was previously firewalled off), while not letting non-SSL users reach any of the webservice subdirectories.
What's the simplest way to ensure that accessing any URL via plain HTTP gets redirected?
You can try adding a filter to the standalone.xml under the subsystem urn:jboss:domain:undertow:4.0
e.g. for http (8080) to https (8443), it would be:
<filter-ref name="http-to-https" predicate="equals(%p,8080)"/>
under the tag filters, you add it:
<rewrite name="http-to-https" target="https://myhttpsurl.com:8443%U" redirect="true"/>

WS Federation (single sign on) module - redirect issue when using SSL offloading

We have a site that we are trying to configure as a client in a SSO scenario, using WS Federation and SAML.
Our site sits behind a load balancer that is doing SSL offloading - the connection to the balancer is under https, but decrypted and forwarded (internally) to the actual site under http and port 81.
Somewhere the WS federation module is attempting to redirect us, but is building up the URL based on the port and incoming protocol to the website:
We request:
https://www.contoso.com/application
and are getting redirected to:
http://www.contoso.com:81/Application
Which doesn't work as the load balancer (correctly) won't respond on this port.
And it seems to be related to the casing of the virtual directory. Browsing to
https://www.contoso.com/Application
seems to work without issue.
(Note for completeness, attempting to browse to http://www.contoso.com/Application with no port will correctly redirect us to the SSL secured URL).
I am trying to find out:
a) Where this redirect is happening in the pipeline and
b) How to configure it to use the correct external address.
If anybody is able to point me in the right direction, I would very much appreciate it.
EDIT 14:19: Seems to be either the WsFederationAuthenticationModule or the SessionAuthenticationModule. These do a case sensitive comparison of the incoming url to what it expects and redirects otherwise:
https://brockallen.com/2013/02/08/beware-wif-session-authentication-module-sam-redirects-and-webapi-services-in-the-same-application/
So that seems to be happening, its a matter now of trying to get the site to behave nicely and redirect to the correct external url.
The following seems to be related and ultimately points to the culprit in the default CookieHandler:
Windows Identity Foundation and Port Forwarding
Looking at that code decompiled in VS, it compares HttpContext.Current.Request.Url against the targetUrl and will redirect to the expected 'cased' version otherwise (in our case including the errant port number).
It would seem that explicitly setting the path attribute of the cookie fixes this issue. Either an empty string or the virtual directory name seems to work:
<federationConfiguration>
<cookieHandler requireSsl="true" name="ContosoAuth" path="/Application/"/>
<wsFederation passiveRedirectEnabled="true" issuer="https://adfsSite" realm="https://www.contoso.com/Application/" reply="https://www.contoso.com/Application/Home" requireHttps="true"/>
</federationConfiguration>

Parse-server SSL IIS

I have tried using serverURL as localhost:1337/parse and publicServerURL as https://mydomaindotcom:1337/parse but I don't know how parse is recognizing the certificate. I don't see a config value to set the cert for parse-server.
Also tried adding cert to IIS 7 to a website on port 443 and using URL Rewrite 2.0 to localhost:1337/parse.
I'm running a self-hosted parse instance using node. parse-server is installed globally. I'm using a config file to start to instance.
Server works fine on http, however I need to utilize https so I can use the rest or js api key without passing headers like so https://myAppID:javascript-key=myJavaScriptKey#mydomaindotcom/classes/GameScore/Ed1nuqPvcm
Any help is much appreciated.
You need to add an https binding that references port 1337 if that is the one that you want to use.

Spinnaker Gate is redirecting to the incorrect authentication URL

So I have spinnaker running behind an https load balancer and my external ports use the standard 443 which get port mapped to the spinnaker instance still on port 9000. I've gotten pretty much everything to work except a redirect from gate is still appending the :9000 port to my URL.
requests sent to https://my.url.com/gate/auth/redirect?to=https://my.url.com/#/infrastructure send back a redirect response with the location header in the 301 location:https://my.url.com:9000/gate/login which fails because the load balancer is only listening for 443. If I manually delete the port and go right to https://my.url.com/gate/login the oauth flow works as expected and once authed all deck functionality and subsequent gate queries work as expected.
In my /etc/default/spinnaker file I have
SPINNAKER_DECK_BASEURL=https://my.url.com
SPINNAKER_GATE_BASEURL=https://my.url.com/gate
in /opt/spinnaker/config/gate-googleOAuth.yml I have
spring:
oauth2:
client:
preEstablishedRedirectUri: ${SPINNAKER_GATE_BASEURL}/login
useCurrentUri: false
and I've ran /opt/spinnaker/bin/reconfigure_spinnaker.sh plus restarts to make sure deck and gate get updated. Does anyone have any ideas what I might be missing?
I figured out my problem. With the help of this issue pointing me in the right direction (https://github.com/spinnaker/spinnaker/issues/1112) and some digging I found that the issue was with apache2 and the reverse proxy back to gate.
ProxyPassReverse
This directive lets Apache httpd adjust the URL in the Location, Content-Location
and URI headers on HTTP redirect responses. This is essential when Apache httpd
is used as a reverse proxy (or gateway) to avoid bypassing the reverse proxy because
of HTTP redirects on the backend servers which stay behind the reverse proxy.
from apache2 documentation https://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypassreverse

SSL offloading / redirecting specific URLs using HAproxy?

I have a working setup using a hardware load balancer that controls redirection in such a fashion that all requests to http://example.com/login/* are redirected (using HTTP 302) to https://example.com/login/* and all requests that are NOT for /login are inversely redirected from HTTPS to HTTP.
This allows me to wrap the login functions and user/password exchange in SSL but otherwise avoid slowing connections with encryption and also solving some problems with embedded content mixed content warnings in some browsers.
The load balance, however, is end of life and I am looking for a replacement solution, preferably in software.
I think HAproxy is going to be able to serve as my load balacing solution, but I have only been able to find configuration examples and documentation for redirecting everything from HTTP to HTTPS, or vice versa.
Is it possible to do what I am proposing using HAproxy or should I look for a different solution?
I realize I will need to use the development version of HAproxy to support SSL at all.
I would suggest you do not use a DEV build for your production environment.
To answer your question, I would assume you're going to use HAProxy version 1.4:
Is it possible to do what I am proposing using HAProxy or should I look for a different solution?
Yes. It is possible but you have to use another software to handle the HTTPS traffic. Stunnel is proven to be good in this. So I'd say the setup is going to be:
HAProxy 1.4
# Redirect http://../login to https://../login
frontend HTTPSRedirect
bind 1.2.3.4:80
default_backend AppServers
redirect prefix https://www.domain.com/login if { path_beg -i /login }
# Handler for requests coming from Stunnel4.
frontend HTTPReceiver
bind 5.6.7.8:80
default_backend AppServers
Stunnel4
[https]
accept=443
connect=5.6.7.8:80 (HAProxy IP)