Use forwarded protocol if a proxy is used

This looks like it should work, but I’m having a hard time testing it and I want to be sure I understand:

Given:

1. Reverse proxy server “www.example.com”
   • Has (for this example) IP address 10.1.2.3
   • Forwards all requests to http://drupal.example.com
   • Correctly sets HTTP_X_FORWARDED_PROTO to https when handing a secure request
2. Drupal server “drupal.example.com”
   • $settings['reverse_proxy'] = TRUE;
   • $settings['reverse_proxy_addresses'] = ['10.1.2.3']

When a request comes in to https://www.example.com/saml/drupal_login/example_idp, it forwards the request to http://drupal.example.com/saml/drupal_login/example_idp.

Without this patch, the <AuthnRequest> goes out with http://... in the useful URLs, but with this patch, it should be https://..., yes?

To test this, I enabled debugging on /admin/config/people/saml_sp and tried

curl -H "HTTP_X_FORWARDED_PROTO: https" http://drupal.example.com

I get the same output regardless of whether I have the patch in place:

[assertionConsumerService] => Array
    (
        [url] => http://d9.lndo.site/saml/consume
        [binding] => urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
     )

It’s possible that my test environment — I’m doing everything on one machine and Drupal is running in a container — is not a sufficient way to test this because Docker or Træfik or something is getting in the way.

Update: I guess I needed to stop staring at it for a little while.

Yes, Træfik was in the way, but I was able to get around it (and also specify the header correctly because ugh PHP), and now it seems to work regardless of whether I have the patch:

curl -H "X-FORWARDED-PROTO: https" http://localhost:57961/saml/drupal_login/example_idp

[assertionConsumerService] => Array
    (
        [url] => https://localhost:57961/saml/consume
        [binding] => urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
     )

I think your verifying the behavior at the wrong place. The problem is that \OneLogin\Saml2\Utils::getSelfURLhost() will return an http URL because it doesn't detect https unless you instruct it to read the forwarded headers.

Also while testing don't forget to set the X-Forwarded-For header as well.

Right, but we care about that because it generates the ACS URL in the <AuthnRequest>. Is there a post-login validation step that fails if OneLogin has the wrong URL (http) even if the right one (https) goes out to the IdP?

I do have one other question: do we need a service for this, or could we do it in the controllers where we initiate and consume the exchange with the IdP?

Can confirm that MR27 fixes this for me. I've got D10 running in an auto-scaling group on AWS behind an Elastic Load Balancer.

The complete fix for me was to add `X-FORWARDED-PROTO` header with the value `https` to the nginx config serving drupal and to also ensure that this is in settings.php:

$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = ['my.ELB.hostname.here']

The last line with the addresses isn't required for this fix btw as the MR only passes the first setting to the SAML library and that combines with the header to trigger the logic. For reference, this is the code that decides on what protocol to use: https://github.com/SAML-Toolkits/php-saml/blob/cadabb78de2590e82fbacbb01...

The attached patch or the Onelogin SAML library doesn't look like it is checking for a proxy or any settings to indicate it is behind a proxy. If that patch is required then I would suggest updating it to check so it doesn't somehow break something else... otherwise the patch should be added to the saml_sp composer.json so it will get automatically applied upon composer install.
Ideally the patch, if required, should be added to an issue file on the onelogin SAML library project.

I think the patches in #1 should be ignored. The MR definitely feels like the correct approach as it basically facilitates the OneLogin SAML library to work as designed.

I am merging.

Automatically closed - issue fixed for 2 weeks with no activity.