Redirect from HTTP POST binding URL to landing page apparently hardcoded to HTTP

[Juan Manuel Palacios]

Good evening!

I'm looking for some help to understand non-fatal behavior that I've been unable to correct. I've searched the official documentation, Google, StackExchange, etc, but so far I've come up empty handed (maybe I'm just not using the right search terms).

My setup is as follows:

1) SimpleSAMLphp 1.14 running on cluster nodes that sit behind an SSL-terminated balancer, running on Ubuntu 16 machines with PHP 5.6.28.

2) Integration with Memcache seems to be successful, and auth handshake between a local SP and a remote IDP (testshib.org) works as expected, i.e. test users can login successfully and get redirected back to the SP landing page, where I can see their attributes.

3) The SSL-terminated nature of my balancer implies that the nodes talk in plain HTTP to it, even though balancer-outbound traffic is always HTTPS. The balancer replies with a 301 "Moved Permanently" response, with the corresponding HTTPS URL as "Location", for every HTTP request that it receives.

4) With this in context, I still managed to force HTTPS ACS URL's in the generated metadata for my test SP by setting a special value for the 'baseurlpath' config setting, i.e. "https://{$_SERVER['SERVER_NAME']}/simplesaml/"

With all of this in mind, auth handshake between the SP and IDP works fine, with one small non-fatal caveat. Once the IDP redirects back to the 'simplesaml/module.php/saml/sp/saml2-acs.php/usf' HTTPS SP URL (with 'usf' being my SP ID), if I'm not mistaken through the HTTP POST binding, the latter then issues the final redirect to the SP's landing page always over HTTP, as opposed to HTTPS.

The caveat is non-fatal because my balancer then takes care of that with a 301 redirect to the HTTPS URL, but I would still like to understand why this is happening. From all I've read so far, this final redirect URL should be HTTPS, since all the ACS URL's in the generated SP metadata are HTTPS. In fact, if I deploy this test SP to a machine that is not fronted by any balancer, and talks directly to the IDP over HTTPS (after generating the exact same SP metadata as in the other deployment), the redirect from the SP HTTP POST binding URL to the landing page does take place straight over HTTPS.

So, all in all, I haven't managed to understand this behavior so far, why the SP HTTP POST binding URL redirects to my landing page over HTTP when using the SSL-terminated balancer. My only hunch is the fact that SimpleSAMLphp is talking to the balancer over plain HTTP, and this protocol is what (perhaps erroneously?) gets used to construct the final redirect URL, but if so I have no idea how to correct it.

Any ideas? Thanks in advance!

[Patrick Radtke]

> Once the IDP redirects back to the 'simplesaml/module.php/saml/sp/saml2-acs.php/usf' HTTPS SP URL (with 'usf' being my SP ID), if I'm not mistaken through the HTTP POST binding, the latter then issues the final redirect to the SP's landing page always over HTTP, as opposed to HTTPS.

So the testshib IdP is POSTing to your SP using HTTP? Are you sure the ACS urls in the metadata you uploaded to testshib were HTTPS? Testshib would look in the metadata for the authorized URLs to send a browser back to.

If you use the samltracer plugin for Firefox you can easily view your SP's authnRequest to testshib and look at what 'AssertionConsumerServiceURL' your SP is sending. Both the one in the authnRequest and the metadata should be https.

[Juan Manuel Palacios]

Hi Patrick, thanks for your reply!

No, the testshib IdP is POSTing to me SP using HTTPS as expected, because all ACS URL's in the SP metadata are indeed HTTPS; I made triple sure of that. What's happening is that the HTTP POST binding URL in the SP is, at the very end of the SAML handshake, sending me to my SP landing page over HTTP, when, if I'm not mistaken, it should be doing so over HTTPS.

The reason why I think that is 1) precisely because all my ACS URL's are HTTPS, and 2) because when I deploy this test SimpleSAMLphp setup to a server that is not fronted by the SSL-terminated balancer, that final SP landing page redirect does happen straight over HTTPS.

When the SSL-terminated balancer is in place, SimpleSAMLphp talks to it (the balancer) over HTTP, even though the ACS URL's are HTTPS (cf. my custom "https://{$_SERVER['SERVER_NAME']}/simplesaml/" 'baseurlpath' config setting), and that's what I think is confusing SimpleSAMLphp into using HTTP for the final landing page redirect.

Does that make sense?

--
You received this message because you are subscribed to the Google Groups "SimpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlphp+unsubscribe@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at https://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.

--

Juan Palacios

Senior Software Architect

135 W. 26th St |12th Fl | NY, NY 10001

Tel: 212.675.9234 | Fax: 646.217.3677
Cell: +58 414.307.00.23

Connect with us! 

Twitter I Linkedin I Facebook I Vimeo

[Patrick Radtke]

Thanks for clearing that up.

What point release of SSP are you on?

There have been a lot of fixes within the base url logic over time which may help you.

I know when I ran 1.14.8 I had issues when using non-standard ports and reverse proxying which I think were fixed in master.

If you go to:

https://servername/simplesaml/admin/hostnames.php

it will print a bunch of diagnostics of what SSP is thinking the hostname is. It might be insightful.

[Juan Manuel Palacios]

I'm on 1.14.11, and I can indeed see HTTPS in use in the info you pointed me to:

HTTP_HOST my.server.com

HTTPS on

SERVER_PROTOCOL HTTP/1.1

SERVER_PORT 443

Utilities_getBaseURL() https://my.server.com/simplesaml/

Utilities_getSelfHost() my.server.com

Utilities_selfURLhost() https://my.server.com

Utilities_selfURLNoQuery() https://my.server.com/simplesaml/admin/hostnames.php

Utilities_getSelfHostWithPath() my.server.com/simplesaml

Utilities_getFirstPathElement() /simplesaml

Utilities_selfURL() https://my.server.com/simplesaml/admin/hostnames.php

But, still, the final redirect to my SP landing page happens over HTTP when the deployment is fronted by the SSL-terminated balancer. Is this something I can correct through some configuration setting? Or is it, perhaps, a minor bug / unexpected behavior in SimpleSAMLphp that is out of my reach?

--
You received this message because you are subscribed to the Google Groups "SimpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlphp+unsubscribe@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at https://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.

[Juan Manuel Palacios]

Patrick,

Actually, I made a mistake. When I posted the hostnames.php info for my SP, I didn't realize I was taking it from the deployment that's not fronted by the SSL-terminated balancer.

I now got it form the original deployment, fronted by the SSL-terminated balancer, and it's actually quite revealing! All URL's remain HTTPS, but:

HTTPS on

is now missing, and

SERVER_PORT 443

turned into:

SERVER_PORT 80

So that, I think, pretty much reveals that, even though I did partly succeed in tricking SimpleSAMLphp into thinking it's operating over HTTPS (due to my fancy "https://{$_SERVER['SERVER_NAME']}/simplesaml/" value for the 'baseurlpath' config setting), it still realizes it's really operating over HTTP behind the balancer. Could that be the explanation for the protocol being used for the final landing page redirect? If so, is there any way I can tweak that behavior?

Thanks in advance for your help!

[Jaime Perez Crespo]

Hi Juan,

If you have specified a canonical HTTPS URL in “baseurlpath”, that’s what SimpleSAMLphp will use to build its metadata, and that’s apparently fine according to your description. If your SP’s metadata has HTTPS endpoints, that’s where the IdP will post it’s response. Also, note that when the IdP sends the response back to your SP, it’s posting a form, not redirecting. An HTTP redirection is a 302 status code, while normal behaviour will be a 200 OK response containing a form that gets submitted automatically. This is important because you keep repeating that “the IdP redirects to my SP”, and that can’t be what’s happening (unless there is something terribly wrong).

My impression from that statement is that this has nothing to do with the SAML exchange. The first thing you need to do is to install and run the SAML tracer plugin in firefox (or some other equivalent in other web browsers) and follow the trace. I suspect that the problem actually is when your very own SP is redirecting back to your application after successful authentication. And that makes full sense given your setup.

If you are offloading TLS to the load balancer and starting authentication from your application using SimpleSAMLphp’s API, when SSP tries to guess the current URL to know where it has to redirect after authentication, HTTPS is OFF. Since the current URL at your application is NOT a URL inside SimpleSAMLphp, we cannot assume whatever you have in “baseurlpath” fits for your application, so we can’t use that to build the current URL. This was a bug in previous versions of SimpleSAMLphp that was fixed recently. Therefore, you need to make sure SSP builds the URL you want it to build because it will no longer try to be smart about it. You have two options at this point:

- build the URL yourself programmatically and pass it to the requireAuth() method as described in the API, or
- set $_SERVER[‘HTTPS’] to “on” in your application code to trick SSP into thinking HTTPS is available.

> To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.

> To post to this group, send email to simple...@googlegroups.com.
> Visit this group at https://groups.google.com/group/simplesamlphp.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
>
>
> Juan Palacios
> Senior Software Architect
>
>
>

> 135 W. 26th St |12th Fl | NY, NY 10001
> Tel: 212.675.9234 | Fax: 646.217.3677
> Cell: +58 414.307.00.23
>
>
> Connect with us!
> Twitter I Linkedin I Facebook I Vimeo
>
>
>
>
>
> --
>
>
> Juan Palacios
> Senior Software Architect
>
>
>
> 135 W. 26th St |12th Fl | NY, NY 10001
> Tel: 212.675.9234 | Fax: 646.217.3677
> Cell: +58 414.307.00.23
>
>
> Connect with us!
> Twitter I Linkedin I Facebook I Vimeo
>
>
>
> --

> You received this message because you are subscribed to the Google Groups "SimpleSAMLphp" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.

> To post to this group, send email to simple...@googlegroups.com.
> Visit this group at https://groups.google.com/group/simplesamlphp.
> For more options, visit https://groups.google.com/d/optout.

--

Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Juan Manuel Palacios]

Hi Jaime,

Thanks for your very helpful reply, you successfully pointed me in the right direction.

You were right, my problem had nothing to do with the SAML exchange, the conversation between my test SP & the external IdP completes pretty uneventfully (and, yes, I was using terminology a tad too flexibly, I'm aware the response from the IdP is not a redirect, but an auto-POST'ed form), and the problem only manifests itself when the SP issues the final redirect back to the application's landing page (and that is, indeed, a 303 "See Other" response).

And you confirmed my suspicion that the HTTP protocol being spoken by SimpleSAMLphp and the SSL-terminated balancer is what's causing the behavior that I want to change. My solution was simply to use the 'RedirectTo' parameter for SimpleSAML_Auth_Simple's requireAuth() method, as I felt tweaking the $_SERVER super-global had a bit of a code-smell to it, and, also, I was already looking for a way to customize where users are taken to after successful authentication.

So, all in all, that suggestion worked wonderfully for me, killed to birds with one stone.

Thanks!

> To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlphp+unsubscribe@googlegroups.com.

> To post to this group, send email to simple...@googlegroups.com.
> Visit this group at https://groups.google.com/group/simplesamlphp.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
>
>
> Juan Palacios
> Senior Software Architect
>
>
>

> 135 W. 26th St |12th Fl | NY, NY 10001
> Tel: 212.675.9234 | Fax: 646.217.3677
> Cell: +58 414.307.00.23
>
>
> Connect with us!
> Twitter I Linkedin I Facebook I Vimeo
>
>
>
>
>
> --
>
>
> Juan Palacios
> Senior Software Architect
>
>
>
> 135 W. 26th St |12th Fl | NY, NY 10001
> Tel: 212.675.9234 | Fax: 646.217.3677
> Cell: +58 414.307.00.23
>
>
> Connect with us!
> Twitter I Linkedin I Facebook I Vimeo
>
>
>
> --

> You received this message because you are subscribed to the Google Groups "SimpleSAMLphp" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlphp+unsubscribe@googlegroups.com.

> To post to this group, send email to simple...@googlegroups.com.
> Visit this group at https://groups.google.com/group/simplesamlphp.
> For more options, visit https://groups.google.com/d/optout.

--

Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

--
You received this message because you are subscribed to the Google Groups "SimpleSAMLphp" group.

To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlphp+unsubscribe@googlegroups.com.

To post to this group, send email to simple...@googlegroups.com.
Visit this group at https://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.

--

Juan Palacios

Senior Software Architect

[Jaime Perez Crespo]

Hi Juan,

Good, glad you solved it!

On 2 Feb 2017, at 00:39 AM, Juan Manuel Palacios <ju...@kognito.com> wrote:
> Hi Jaime,
>
> Thanks for your very helpful reply, you successfully pointed me in the right direction.
>
> You were right, my problem had nothing to do with the SAML exchange, the conversation between my test SP & the external IdP completes pretty uneventfully (and, yes, I was using terminology a tad too flexibly, I'm aware the response from the IdP is not a redirect, but an auto-POST'ed form), and the problem only manifests itself when the SP issues the final redirect back to the application's landing page (and that is, indeed, a 303 "See Other" response).
>
> And you confirmed my suspicion that the HTTP protocol being spoken by SimpleSAMLphp and the SSL-terminated balancer is what's causing the behavior that I want to change. My solution was simply to use the 'RedirectTo' parameter for SimpleSAML_Auth_Simple's requireAuth() method, as I felt tweaking the $_SERVER super-global had a bit of a code-smell to it, and, also, I was already looking for a way to customize where users are taken to after successful authentication.
>
> So, all in all, that suggestion worked wonderfully for me, killed to birds with one stone.