Documentation

A SAML assertion carries a Destination attribute naming the exact URL it may be delivered to, and it is only accepted at that URL. With TLS terminated at a proxy, PHP only ever sees the plain http request the proxy made internally, so the URL reconstructed from $_SERVER never matches the public https one the identity provider addressed the assertion to.

The login fails, nothing appears on screen, and the login form comes back. There is no error, no warning in the browser, and no hint that TLS has anything to do with it. The tell is that the same setup works locally over plain http and only breaks once it goes behind a proxy.

The reason is recorded—see Logging—and it names both URLs, which makes the mismatch obvious:

The extension hands TYPO3's own view of the current URL to the SAML toolkit rather than letting the toolkit reconstruct it, so the usual TYPO3 proxy configuration is all that is needed:

Only host, protocol, and port are handed over. The path is deliberately left alone, for the reason in What Not to Do.

Is the public host name reaching TYPO3? The proxy has to pass it on, either as Host or as X-Forwarded-Host—the latter requires reverseProxyHeaderMultiValue. A wrong host is as fatal as a wrong scheme and shows up identically.

Does the installation live under a path prefix on the proxy? Then reverseProxyPrefix and reverseProxyPrefixSSL have to state it, or the path part of the URL is wrong.

Is the port right? A Host header without a port is treated as 443 for https and 80 for http, rather than falling back to the container-internal port the proxy connected to. A proxy that forwards to a non-standard public port has to put that port in the Host header.

Do not set the SAML toolkit's own baseurl setting to work around this. It overrides the detection described above, and it additionally rewrites the path, which cuts a nested route such as /typo3/auth/sso/acs down to /acs. The result is a different mismatch that is harder to recognize, because the host and scheme then look correct.