Bug #9591
SAML 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