Problem with 1.19.0 SP, Shibboleth IdP and Chrome

[Jörn C.]

Hi!

I am currently using SimpleSAMLphp 1.18.8 as SP for MediaWiki. A few days ago I tried switching to 1.19.0, and I could still successfully log in. Other users reported problems, though. It turned out, that they were using Chrome or Chromium-based browsers, I am using Firefox.

After entering the credentials for the IdP, instead of getting redirected to MediaWiki, a warning is shown in the browser (according to the URL still generated by the IdP):

" Note: Since your browser does not support JavaScript, you must press the Continue button once to proceed."

Pressing the "Continue" button leads back to this page, now with an attribute "SAMLRequest" encoded into the URL, and every following press of the button will generate another value for SAMLRequest.

When JavaScript is allowed in Chrome, this process is automated, i.e. you enter a loop of constantly reloading this page.

Although this loop seems to happen on the IdP, downgrading to SimpleSAMLphp 1.18.8 fixed the problem for me. The IdP in question is Shibboleth 4.0.1.

My  main question for the moment: Can anyone confirm this behavior?

[Tim van Dijen]

Hi Jörn,

I think the issue described is the same as the one reported here;

https://github.com/simplesamlphp/simplesamlphp/issues/1444

The reporter couldn't help us much with debugging-information, but we suspect it may have something to do with sameSite cookies..
Can you do a test-run with the browser developer tools to see if it reports any issues in this regard?

- Tim

Op maandag 22 maart 2021 om 15:26:50 UTC+1 schreef Jörn C.:

[Jörn C.]

Hi Tim!

Yes, that looks familiar. I'll try to collect some more information and attach them to the GitHub issue.

[Tim van Dijen]

That would be great, thanks Björn!

One other thing that may be interesting to know is what happens if you set 'session.cookie.samesite' => 'None' to rule out the new logics that try to determine this setting automatically.

- Tim

Op maandag 22 maart 2021 om 15:56:49 UTC+1 schreef Jörn C.:

[Tim van Dijen]

One more thing that comes to mind;  since I couldn't reproduce it with a native SSP SP, we may have to rule out MediaWiki and/or MediaWiki<> SSP integration as part of the issue.

I'm not familiar with MediaWiki, but I'm assuming some kind of plugin is in effect that uses SSP?

Op maandag 22 maart 2021 om 16:02:18 UTC+1 schreef Tim van Dijen:

[Tim van Dijen]

One final thing.. If you're not too worried about revealing your hostname, it would _really_ help if you can generate a SAML-trace using the SAML-tracer plugin for Chrome.
The resulting trace can be rid of any personal data by masking attribute values, so there shouldn't be a privacy issue.  You could even send it to me personally, even through encrypted email if it concerns you.

I'd really like to smash this bug!

- Tim

Op maandag 22 maart 2021 om 17:06:55 UTC+1 schreef Tim van Dijen:

[Sorin Gheorghiu]

Hi Jörn,

I use SimpleSAMLphp und MediaWiki as well and I cannot confirm this behavior with Chrome after upgrading from 1.18.8 to 1.19.0, the issue could be related to your IDP

Cheers,
Sorin

--
This is a mailing list for users of SimpleSAMLphp, not a support service. If you are willing to buy commercial support, please take a look here:
 
https://simplesamlphp.org/support
 
Before sending your question, make sure it is related to SimpleSAMLphp, and not your web server's configuration or any other third-party software. This mailing list cannot help with software that uses SimpleSAMLphp, only regarding SimpleSAMLphp itself.
 
Make sure to read the documentation:
 
https://simplesamlphp.org/docs/stable/
 
If you have an issue with SimpleSAMLphp that you cannot resolve and reading the documentation doesn't help, you are more than welcome to ask here for help. Subscribe to the list and send an email with your question. However, you will be expected to comply with some minimum, common sense standards in your questions. Please read this carefully:
 
http://catb.org/~esr/faqs/smart-questions.html
---
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 view this discussion on the web visit https://groups.google.com/d/msgid/simplesamlphp/23801d23-741b-4328-9cf1-455900bcab41n%40googlegroups.com.

-- 
Sorin Gheorghiu             Tel: +49 7531 88-3198
Universität Konstanz        Raum: B705
78464 Konstanz              sorin.g...@uni-konstanz.de

- KIM: Abteilung IT-Dienste Forschung und Lehre -

[Dubravko Penezic]

Hi all,

according my experiance please check in SSP config/config.php
configuration if you have set |'session.cookie.secure' => false, it need
to be |
||'session.cookie.secure' => true , also check what is value of ||
||session.cookie.samesite , in most case it need to be None or other
value if you know how to use it.||

||Regards,||

||Dubravko Penezic

||

On 3/22/21 6:01 PM, Sorin Gheorghiu wrote:
>
> Hi Jörn,
>
> I use SimpleSAMLphp und MediaWiki as well and I cannot confirm this
> behavior with Chrome after upgrading from 1.18.8 to 1.19.0, the issue
> could be related to your IDP
>
> Cheers,
> Sorin
>
>
> Am 22.03.2021 um 15:26 schrieb Jörn C.:
>> Hi!
>>
>> I am currently using SimpleSAMLphp 1.18.8 as SP for MediaWiki. A few
>> days ago I tried switching to 1.19.0, and I could still successfully
>> log in. Other users reported problems, though. It turned out, that
>> they were using Chrome or Chromium-based browsers, I am using Firefox.
>>
>> After entering the credentials for the IdP, instead of getting
>> redirected to MediaWiki, a warning is shown in the browser (according
>> to the URL still generated by the IdP):
>>

>> " *Note:*Since your browser does not support JavaScript, you must

>> <mailto:simplesamlph...@googlegroups.com>.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/simplesamlphp/23801d23-741b-4328-9cf1-455900bcab41n%40googlegroups.com

>> <https://groups.google.com/d/msgid/simplesamlphp/23801d23-741b-4328-9cf1-455900bcab41n%40googlegroups.com?utm_medium=email&utm_source=footer>.

> --
> Sorin Gheorghiu Tel: +49 7531 88-3198
> Universität Konstanz Raum: B705

> 78464 Konstanzsor...@uni-konstanz.de

>
> - KIM: Abteilung IT-Dienste Forschung und Lehre -

> --
> This is a mailing list for users of SimpleSAMLphp, not a support
> service. If you are willing to buy commercial support, please take a
> look here:
>
> https://simplesamlphp.org/support
>
> Before sending your question, make sure it is related to
> SimpleSAMLphp, and not your web server's configuration or any other
> third-party software. This mailing list cannot help with software that
> uses SimpleSAMLphp, only regarding SimpleSAMLphp itself.
>
> Make sure to read the documentation:
>
> https://simplesamlphp.org/docs/stable/
>
> If you have an issue with SimpleSAMLphp that you cannot resolve and
> reading the documentation doesn't help, you are more than welcome to
> ask here for help. Subscribe to the list and send an email with your
> question. However, you will be expected to comply with some minimum,
> common sense standards in your questions. Please read this carefully:
>
> http://catb.org/~esr/faqs/smart-questions.html
> ---
> 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

> <mailto:simplesamlph...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/simplesamlphp/64248884-065d-8ccd-76e7-13aab1ddefb4%40uni-konstanz.de
> <https://groups.google.com/d/msgid/simplesamlphp/64248884-065d-8ccd-76e7-13aab1ddefb4%40uni-konstanz.de?utm_medium=email&utm_source=footer>.

[Jörn C.]

Hi all!

Thanks for the many responses. Indeed, the integration with MediaWiki is not the problem, the same error occurs when testing authentication from the internal SSP page. But Shibboleth as IdP seems to be a factor.

Changing "session.cookie.secure" from "false" to "true" indeed fixed most of the problem for me. One annoyance is, after authentication, before the IdP sends me back to my service, I still get "your browser does not support JavaScript" and I have to press the "Continue" button, but now that takes me back to the correct page. This does not happen when switching back to SSP 1.18.8. Allowing JavaScript in the browser is of course an option - unless it is turned off by policy.

[Peter Schober]

* Jörn C. <joernc...@gmail.com> [2021-03-24 16:02]:

> One annoyance is, after authentication, before the IdP sends me back
> to my service, I still get "your browser does not support
> JavaScript" and I have to press the "Continue" button, but now that
> takes me back to the correct page. This does not happen when
> switching back to SSP 1.18.8. Allowing JavaScript in the browser is
> of course an option - unless it is turned off by policy.

JFYI this is normal behaviour of the Shibboleth IDP -- and of any
other I know of: The way SAML WebSSO profile works is by having the
subject's browser mediate the transfer of data from the IDP to the SP
by means of the browser submitting an IDP-populated HTML form
(containing the encoded SAML response as payload) with the form's
action pointing to the SP. (See the SAML specs for details.)
The only way to avoid the subject from having to submit that form is
autosubmitting it using JS, AFAIK.

Of course running a browser with JavaScript disabled in 2021 will
break the web for you, all the time, so the "annoyance" of having to
click once to complete the SSO process will be the *least* of your
problems and with 1 extra click everything still fully works.
Not something that could be said about the rest of the broken shit
show that once was the web.
(I'm saying that as someone running Firefox in "strict" mode and with
all 3rd party cookies disabled and with Enhanced Tracking Protection
enabled. Half the web is unusable that way, so I'll stick to the parts
I still can use. ;))

-peter

[Jörn C.]

Setting "session.cookie.secure" back to "false", the Chrome debugger shows, that the cookies "SimpleSAMLSessionID" and "SimpleSAMLAuthToken" are denied, because "SameSite" is set to "none", but they are not marked "Secure".

I also tried changing "network.cookie.sameSite.noneRequiresSecure" in Firefox from "false" to "true" and expected the same problem, but authentication still worked as before (although I can't rule out that I need to restart Firefox for this change to take effect).

[Peter Schober]

* Jörn C. <joernc...@gmail.com> [2021-03-24 16:27]:

> Setting "session.cookie.secure" back to "false", the Chrome debugger shows,
> that the cookies "SimpleSAMLSessionID" and "SimpleSAMLAuthToken" are
> denied, because "SameSite" is set to "none", but they are not marked
> "Secure".

There's no excuse for running anything on involving SAML (SP and
certainly not IDP) without TLS today, so the software should at least
allow to easily mark any and all of its own cookies as "secure".
Is that not the case?

-peter

[Jörn C.]

JFYI this is normal behaviour of the Shibboleth IDP

Although I agree completely ;), using the same browser (with JS turned off) and the same IdP, only switching back from SSP 1.19.0 to 1.18.8, the need to click the button is gone. So something in SSP 1.19 seems to have changed. But as you pointed out: If you are using the current web without JavaScript, you probably know what you are doing and have earned a respectable capacity for suffering...

[Tim van Dijen]

This is the case if you 1) run your webserver with https on, or 2) if you're behind a reverse proxy and have properly set the baseurlpath config-setting to the external https-url, or 3) have set session.cookie.secure to true..

We can't always guess every sketchy setup, but will make it work automagically for the cases we can detect.

- Tim

Op woensdag 24 maart 2021 om 16:29:25 UTC+1 schreef Peter Schober: