Getting Runtime Error related to http vs https

I can only give you a next step for debugging. Because it feels like those various *_header variables in settings.php are not matching whatever headers are being forwarded from your load balancer / reverse proxy.

To doublecheck:

• Check "Use Drupal base URL in toolkit library" and uncheck "Use 'X-Forwarded-*' headers (deprecated)", for future/forward compatibility.
• In SamlService::getSamlAuth(), under the
  

  $base_url = $request->getSchemeAndHttpHost() . $request->getBaseUrl() . '/saml';
  

  , log your $base_url somehow. (Note this will likely be 'spamming' the logs.)

If that reports http and not https... then something's wrong with your config vs the reverse proxy headers. That $request->getSchemeAndHttpHost() is a call into Symfony code, which gets the settings.php *_header settings inserted to determine isSecure(). And if I understand correctly, you always want this to be "https".

I did this: Check "Use Drupal base URL in toolkit library" and uncheck "Use 'X-Forwarded-*' headers (deprecated)", for future/forward compatibility.

and then I added a logger to capture $base_url. i then tried to login. Checked the logs and I got three entries for my additional logger and they were all:

https://REDACTED.net/saml
So it seems that base_url IS getting the https url

Is there something else I can try next?

OK. That means your setup is configured correctly. It also means that I cannot (from just reading code) see what is going on:

• The error is in vendor/onelogin/php-saml/src/Saml2/Response.php, line 285-289 (unless you have a library version I don't know)
• suggesting $currentURL = Utils::getSelfRoutedURLNoQuery() is "http".
• In Response::__construct(),
  • Your $base_url should be injected (through Settings), so
  • $this->_settings->getBaseURL() should return that value
  • and Utils::setBaseURL($baseURL) should be called with that value
• and if I'm reading the code right, Utils::getSelfRoutedURLNoQuery() should return that value, i.e. your $base_url, i.e. "https"

I don't see where the inconsistency is. That's all I can give you as hints for debugging. (I don't remember this issue being reported earlier.)

If you feel compelled to hack Response.php to work around throwing that ValidationError: (it generally shouldn't be necessary but) in this specific case, that wouldn't introduce any security holes.

(Also I see that the error is not thrown if you turn off the "strict" option, but I can't say that's a good idea.)

This can be closed. Thanks for all the tips and help.