1

I have been testing SAML 2.0 for the past few days using simplesamlphp. I have the SP side connecting to my company's IdP. I am in a situation where it works... most of the times and this is the confusing part. The facts:

  • Using simplesamlphp 1.14.2 on RHEL 7 with apache 2.4
  • I am testing by log-in and out many times
  • My site/service is working over https. The same applies for simplesamlphp. The IdP is http
  • IdP configuration was auto-generated via the build-in XML parser. We are using SHA256 and singing the logout messages with self-signed certificate
  • It works! 95% of the time in Firefox and Chrome, which is good enough for me but it makes my service not production ready...
  • The other 5% throws an error similar to this: "Unable to find the current binding.". The difference is that in my logs it appears as:

    Oct 21 17:30:15 simplesamlphp WARNING [6b6e3c270f] Unable to find the SAML 2 binding used for this request.array (\n)
    Oct 21 17:30:15 simplesamlphp WARNING [6b6e3c270f] Request method: 'GET'array (\n)
    

    The above is just an example modified from the previous post. Note that I do see array in both lines. I have looked into the source code that logs this error and I cannot figure out why it is there (not sure it matters either way - seems to be introduced by the logging facility)

  • This is where things get weird! I sometimes get the usual (on infinite recursion or so) PHP error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes). In my case X is 256M but Y is 2+G!!! This is rare but it happens. When it happens PHP is not of much help, it says that it happened in "unknown line 0":

    [18-Apr-2016 12:07:18 Europe/London] PHP Fatal error:  Allowed memory size of 262144000 bytes exhausted (tried to allocate 2480381656 bytes) in Unknown on line 0
    
  • Some times the logs show no errors but the browser is complaining about empty response

  • Edge/IE browser seems to get confused a lot easier (no surprise there :)) but it produces the same logs. For example, the empty response shows as a "Couldn't load page" error that in turn suggests a DNS failure.

  • Most of the times using the back button makes everything work. Not all of the times... there are time that it gets stuck, in which case the simplesamlphp error page appears and the error can vary (SimpleSAML_Error_Error: SLOSERVICEPARAMS). The URL points at simplesamlphp and not the service or the IdP, thus refreshing leads to the error page again. After refresh, hitting back is pointless leading to a loop back to the error page

My thoughts:

  • It does not seem like a config error. It would be reproduce-able if it was... IdP is happy to sign us in and out
  • It shouldn't be browser specific
  • PHP allocating to much memory lead me to believe there is a bug somewhere but 1.14 is the latest stable

UPDATE 1:

Related (same error) - https://groups.google.com/forum/#!topic/simplesamlphp/C8XAQblAECU

UPDATE 2:

After a lot of reading and a lot of logs, I think I have a session conflict between SSP and my application. Removing all the session related code from the application, make SSP work like charm. With my session code I see the following errors:

  • PHP Warning: Unknown: Could not call the sapi_header_callback in Unknown on line 0
  • PHP Notice: Trying to get property of non-object in �5� on line 352
  • Unsuccessful logout. Status was: exception 'sspmod_saml_Error' with message 'Requester' in

I believe that most (if not all) of the errors above are due to some weird state in SSP and session, that wouldn't normally appear. So my new, simpler question:

Has anyone configured successfully SSP 1.14.2 with store.type = 'sql' and SQLite? I can see the sqlite file being created along with few tables in it, but SSP always comes back with "no state" error. I believe that changing the store to SQL will solve my problem...

Cheers

Community
  • 1
  • 1
urban
  • 5,392
  • 3
  • 19
  • 45

1 Answers1

6

I know this question seems to be all over the place and very very confusing ... imagine looking at the logs :)

Now, with the help of jaimeperez - SSP (SimpleSamlPhp) developer on github - we have broken this down to multiple "simpler" issues:

  1. Session sharing: When both the application and SSP are using $_SESSION you have to:

    • Use the recently released SSP 1.14.3 which provides a fix for such cases
    • Name your sessions. In your application use session_name("XYZ") before you call session_start() and in SSP's config.php set a non-default value to the session.phpsession.cookiename. Based on my tests, both have to be non-default (not "PHPSESSID"). The php.ini option to autostart session might affect that (ie: if set to false one of the two can use the default - not tested)
  2. Errors that arise from a PHP bug in version 5.4.16. This makes PHP SegFault leaving SSP in a wrong state. This has nothing to do with SSP and is mainly an issue with RHEL/Centos 7 and PHP. This addresses the errors:

    • Allowed memory size of X bytes exhausted ... in Unknown on line 0
    • PHP Warning: Unknown: Could not call the sapi_header_callback in Unknown on line 0 and
    • PHP Notice: Trying to get property of non-object in �5� on line 352 (or similar! differs every time! but it is an error pointing to Session.php line 352 - which also seems completely irrelevant)

    The solution to this one is to upgrade PHP. From what I read, the issue is fixed in 5.4.20 and 5.5.2 (TBC)

  3. The error Unsuccessful logout. Status was: exception 'sspmod_saml_Error'... is due to the IdP refusing to serve me because I login and logout too many times, too fast as part of the testing

I usually close my answer with the phrase "I hope this helps"... but in this case I really hope you are not in a similar situation :) Hopefully, the question and this answer contain enough keywords to make google point here...

If you want to follow the conversation about this, you can do so on github

urban
  • 5,392
  • 3
  • 19
  • 45
  • "In your application use session_name("XYZ") before you call session_start() and in SSP's config.php set a non-default value to the session.phpsession.cookiename" This worked for one of the issue I faced, but I still want to know what is the reason behind configuring like this only. – curious_pawn Dec 17 '20 at 20:09