Bug #9591
closedSAML Authentication Behind TLS Terminating Reverse Proxy
100%
Description
I'm very excited about SAML support being added. Thank you so much!
I'm trying to get it to work with Microsoft Azure AD, and I'm running into an issue. I run my Wt application in Kubernetes. Our Kubernetes uses nginx to terminate TLS connections and then reverse proxy to my Wt application. This works in general, but in the case of SAML authentication, I get this error:
[error] "Auth.Saml.Service: OpenSAML.MessageDecoder.SAML2POST (thread: 140186616833792): POST targeted at (https://<host>/acs), but delivered to (http://<host>/acs)"
I did some investigation, and it appears that the appendOriginalUrl
function in the Wt::Auth::Saml::Service
class creates an "original URL" based on the request that was POST'ed to the "/acs" endpoint, but that the request returns "http" for the URL scheme, instead of "https". Technically the request is right, it is an "http" request, but in this situation, the "original URL" needs to be one that is on the other side of the reverse proxy. My reverse proxy is sending some helpful header to assist with this:
X-Forwarded-For: 127.0.0.1
X-Forwarded-Host: <host>
X-Forwarded-Port: 443
X-Forwarded-Proto: https
Would it be possible to get support for SAML from behind a reverse proxy?
Files
Updated by Roel Standaert almost 3 years ago
- Status changed from New to Confirmed
- Target version set to 4.6.2
At first, I was thinking you just didn't configure <trusted-proxy-config>
(or the deprecated <behind-reverse-proxy>
, but it seems we indeed do not look at that yet in Wt::Http::Request::urlScheme()
, so that will have to be fixed.
Updated by Roel Standaert almost 3 years ago
- Target version changed from 4.6.2 to 4.7.0
I guess I'll set this to 4.7.0, since it's still an observable change in default behavior.
Updated by Aaron Wright almost 3 years ago
Roel Standaert wrote in #note-2:
I guess I'll set this to 4.7.0, since it's still an observable change in default behavior.
In the mean time, I would appreciate a patch for 4.6.1. :)
I got everything to work this weekend by hardcoding "https" in the appendOriginalUrl
, but I don't want to ship like that, obviously.
FYI, on a side topic, that <trusted-proxy-config>
setting is hard for me to use in my Kubernetes environment. I don't know the IP addresses of the reverse proxy server. I get connections from several different IP addresses so there must be load balancing going on up front, and I have a feeling that the addresses can change when the department in charge of Kubernetes decides to redeploy something. I guess I could set the <trusted-proxy-config>
to 0.0.0.0/0
, and call that good.
Updated by Roel Standaert almost 3 years ago
I think you may still be able to define a certain broader range that's not quite 0.0.0.0/0
?
Of course, if you're sure that your application server is never directly accessed from the outside you can set it to 0.0.0.0/0
.
Updated by Roel Standaert almost 3 years ago
- Status changed from Confirmed to InProgress
Updated by Roel Standaert almost 3 years ago
- Status changed from InProgress to Review
Updated by Roel Standaert almost 3 years ago
- File 0001-WT-9591-make-Http-Request-urlScheme-look-at-X-Forwar.patch 0001-WT-9591-make-Http-Request-urlScheme-look-at-X-Forwar.patch added
I attached the patch that is currently in review for inclusion in Wt 4.7.0.
Updated by Aaron Wright almost 3 years ago
Roel Standaert wrote in #note-7:
I attached the patch that is currently in review for inclusion in Wt 4.7.0.
Thanks so much! That's some good customer service.
I tested the patch and it does work for me.
Updated by Roel Standaert almost 3 years ago
- Status changed from Review to Implemented @Emweb
- % Done changed from 0 to 100
Updated by Roel Standaert almost 3 years ago
- Status changed from Implemented @Emweb to Resolved
Updated by Roel Standaert almost 3 years ago
- Status changed from Resolved to Closed