urban
urban

Reputation: 5702

SimpleSamlPhp (SSP): "Random" errors - how to change backend/store?

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:

My thoughts:

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:

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

Upvotes: 1

Views: 1724

Answers (1)

urban
urban

Reputation: 5702

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

Upvotes: 6

Related Questions