Project

General

Profile

Bug #9591

SAML Authentication Behind TLS Terminating Reverse Proxy

Added by Aaron Wright 5 months ago. Updated 2 months ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
01/09/2022
Due date:
% Done:

100%

Estimated time:

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

Also available in: Atom PDF