SimpleSAMLphp 1.14.5

[Jaime Perez Crespo]

Hi,

We have just released SimpleSAMLphp version 1.14.5. This is a bugfix release, resolving compatibility issues with Windows hosts, PHP 5.3 and PHP 7.X, as well as an issue with self URL generation and better recovery from failures to initialize a session. It fixes also the authwindowslive module, which had stopped working previously.

As usual, we recommend everybody to update to this release as soon as possible.

The changelog and upgrade notes are available here, respectively:

https://simplesamlphp.org/docs/1.14/simplesamlphp-changelog#section_1

https://simplesamlphp.org/docs/1.14/simplesamlphp-upgrade-notes-1.14

This new release is available for download here:

https://github.com/simplesamlphp/simplesamlphp/releases/download/v1.14.5/simplesamlphp-1.14.5.tar.gz

You can verify the integrity of this file by comparing the SHA256 digest: f1d28cccd1fd23b2e796bbc8af04ac7048ac010ac69805c1939442686528a5a4

Regards,

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

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

[Tim van Dijen]

Hi Jaime,

Unfortunately I'm running into an issue with this new build.
I am using SSP in a test-environment as both an IdP as an SP (the default 'My first SP' page).
As I get redirected back from the IdP to the SP, I'm being sent to some faulty combination of url+script path:

POST https://gdisx0066.example.nl/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp HTTP/1.1
Host: gdisx0066.example.nl
Referer: https://login.someotherexample.nl/module.php/core/loginuserpass.php?

HTTP/?.? 303 See Other
Server: Apache
Location: https://gdisx0066.example.nl/simplesaml//apps/simplesamlphp-demo/www/index.php
POST https://gdisx0066.example.nl/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp HTTP/1.1
Host: gdisx0066.example.nl
Referer: https://login.someotherexample.nl/module.php/core/loginuserpass.php?

HTTP/?.? 303 See Other
Server: Apache
Location: https://gdisx0066.example.nl/simplesaml//apps/simplesamlphp-demo/www/index.php

I've narrowed the issue down to the /lib/SimpleSAML/Utils/HTTP.php file.. When I swap back that file to the 1.14.4 version, everything is fine and dandy again.
I need some help on this.. Is this a bug or a misconfiguration on my end?

Tim

Op dinsdag 12 juli 2016 15:02:23 UTC+2 schreef Jaime Pérez:

[Jaime Perez Crespo]

Hi Tim!

It is a bug, yes:

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

And it has also been fixed:

https://github.com/simplesamlphp/simplesamlphp/commit/8590d06507ce08d1fea67ed44b72e99756747b29

It would be great if you can confirm that this fix solves the issue for you. It apparently works, so we’ll need another bugfix release, I’m afraid.

Thanks for the heads up!

On 16 Jul 2016, at 09:46 AM, Tim van Dijen <tvd...@gmail.com> wrote:
> Hi Jaime,
>
> Unfortunately I'm running into an issue with this new build.
> I am using SSP in a test-environment as both an IdP as an SP (the default 'My first SP' page).
> As I get redirected back from the IdP to the SP, I'm being sent to some faulty combination of url+script path:
>
> POST https://gdisx0066.example.nl/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp HTTP/1.1
> Host: gdisx0066.example.nl
> Referer: https://login.someotherexample.nl/module.php/core/loginuserpass.php?
>
> HTTP/?.? 303 See Other
> Server: Apache
> Location: https://gdisx0066.example.nl/simplesaml//apps/simplesamlphp-demo/www/index.php
> POST https://gdisx0066.example.nl/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp HTTP/1.1
> Host: gdisx0066.example.nl
> Referer: https://login.someotherexample.nl/module.php/core/loginuserpass.php?
>
> HTTP/?.? 303 See Other
> Server: Apache
> Location: https://gdisx0066.example.nl/simplesaml//apps/simplesamlphp-demo/www/index.php
>
> I've narrowed the issue down to the /lib/SimpleSAML/Utils/HTTP.php file.. When I swap back that file to the 1.14.4 version, everything is fine and dandy again.
> I need some help on this.. Is this a bug or a misconfiguration on my end?
>
> Tim

[Tim van Dijen]

Hey Jaime,

I can confirm that this fixes the issue for me!

[Robert Wolf]

> We have just released SimpleSAMLphp version 1.14.5.

> We have just released SimpleSAMLphp version 1.14.6.
> We have just released SimpleSAMLphp version 1.14.7.


Hello Jaime and others,

has anyone already reported following problem?

We use SSP as SP and IdP. Currently we have version 1.14.4 on Debian Squeeze,
Wheezy and Jessie. I have updated SSP on one testing Debian Jessie SP server to
version 1.14.7. The IdP on Debian Wheezy has still 1.14.4.

Debian Jessie comes with PHP 5.6.24.

I try to access SP, then SSP redirects to IdP, login is OK and IdP redirects
back to SP. But now, SP starts redirecting and there are following errors in
the log:


Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] SimpleSAML_Error_Exception: Error 2 - Unknown: The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,'
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] Backtrace:
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] 1 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/www/_include.php:83 (SimpleSAML_error_handler)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] 0 [builtin] (N/A)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] SimpleSAML_Error_Exception: Error 2 - Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5/sessions)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] Backtrace:
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] 1 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/www/_include.php:83 (SimpleSAML_error_handler)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] 0 [builtin] (N/A)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] SimpleSAML_Error_Exception: Error 2 - session_write_close(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,'
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] Backtrace:
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 6 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/www/_include.php:83 (SimpleSAML_error_handler)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 5 [builtin] (session_write_close)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 4 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/lib/SimpleSAML/SessionHandlerPHP.php:349 (SimpleSAML_SessionHandlerPHP::setCookie)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 3 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/lib/SimpleSAML/Session.php:164 (SimpleSAML_Session::__construct)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 2 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/lib/SimpleSAML/Session.php:281 (SimpleSAML_Session::getSessionFromRequest)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 1 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/lib/SimpleSAML/Auth/Simple.php:76 (SimpleSAML_Auth_Simple::requireAuth)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 0 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/www/authmemcookie.php:36 (N/A)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] SimpleSAML_Error_Exception: Error 2 - session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5/sessions)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] Backtrace:
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 6 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/www/_include.php:83 (SimpleSAML_error_handler)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 5 [builtin] (session_write_close)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 4 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/lib/SimpleSAML/SessionHandlerPHP.php:349 (SimpleSAML_SessionHandlerPHP::setCookie)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 3 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/lib/SimpleSAML/Session.php:164 (SimpleSAML_Session::__construct)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 2 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/lib/SimpleSAML/Session.php:281 (SimpleSAML_Session::getSessionFromRequest)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 1 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/lib/SimpleSAML/Auth/Simple.php:76 (SimpleSAML_Auth_Simple::requireAuth)
Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [2a3e177d45] 0 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/www/authmemcookie.php:36 (N/A)


The PHP5 checks if the session ID contains only allowed characters, but since
SSP 1.14.5 the function SimpleSAML_SessionHandlerPHP::setCookie() sets to PHP
Session ID (using session_id() function) to own random generated ID from
SimpleSAML\Utils\Random::generateID(), which begins with "_".

If I change the "_" to "a" in the generateID(), the PHP reports no error
anymore, character "a" is allowed. But the SP redirects again back to IdP until
web browser reports "The page isn't redirecting properly".

If the DEBUG logging is activated, I can see the correct SAML login and then
during redirects it writes to log:

Session: Valid session found with 'SP'

I haven't changed configuration between 1.14.4 and 1.14.7. Have I missed some
config option update for new versions?

Does anyone has the same problems? Do you have any idea, what is the problem.

I downgrade this server to 1.14.4 and test the 1.14.7 on the SSO test server
and I try to find the reason causing this functionality, but maybe someone
knows exactly, where is the problem.


Thank you for your help and ideas.

Regards,

Robert Wolf.

[Jaime Perez Crespo]

Hi Robert,

Please see my comments inline:

On 03 Aug 2016, at 13:56 PM, Robert Wolf <r.wol...@atlas.cz> wrote:
> Hello Jaime and others,
>
> has anyone already reported following problem?

Not that I’m aware of.

> We use SSP as SP and IdP. Currently we have version 1.14.4 on Debian Squeeze,
> Wheezy and Jessie. I have updated SSP on one testing Debian Jessie SP server to
> version 1.14.7. The IdP on Debian Wheezy has still 1.14.4.
>
> Debian Jessie comes with PHP 5.6.24.
>
> I try to access SP, then SSP redirects to IdP, login is OK and IdP redirects
> back to SP. But now, SP starts redirecting and there are following errors in
> the log:
>
> Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] SimpleSAML_Error_Exception: Error 2 - Unknown: The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,'
> Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] Backtrace:
> Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] 1 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/www/_include.php:83 (SimpleSAML_error_handler)
> Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] 0 [builtin] (N/A)
> Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] SimpleSAML_Error_Exception: Error 2 - Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5/sessions)

This is likely to be an issue. Have you verified that your web server can write new files to that path?

No, it doesn’t. This is the method that generates an ID for the session, the one that setCookie() is setting latter on by calling session_id():


/**
* Create a new session id.
*
* @return string The new session id.
*/
public function newSessionId()
{
// generate new (secure) session id
$sessionId = bin2hex(openssl_random_pseudo_bytes(16));
SimpleSAML_Session::createSession($sessionId);

return $sessionId;
}

As you can see, no underscores at all.

> If I change the "_" to "a" in the generateID(), the PHP reports no error
> anymore, character "a" is allowed. But the SP redirects again back to IdP until
> web browser reports "The page isn't redirecting properly".
>
> If the DEBUG logging is activated, I can see the correct SAML login and then
> during redirects it writes to log:
>
> Session: Valid session found with 'SP'
>
> I haven't changed configuration between 1.14.4 and 1.14.7. Have I missed some
> config option update for new versions?
>
> Does anyone has the same problems? Do you have any idea, what is the problem.

Well, if this was an issue as you are describing it, SimpleSAMLphp would be unusable with PHP sessions. I find it unlikely then that nobody mentioned this so far, if that was the case. Furthermore, I’ve tested these last releases extensively with both the PHP and Memcache session handlers, since there were a lot of changes there fixing bugs, and they work just fine. I have just verified indeed that the session IDs generated do not contain any underscores and that sessions work fine when PHP is managing them.

> I downgrade this server to 1.14.4 and test the 1.14.7 on the SSO test server
> and I try to find the reason causing this functionality, but maybe someone
> knows exactly, where is the problem.

My guess is that you have some collision with the session cookie between SimpleSAMLphp and some other application, causing trouble to SimpleSAMLphp. Recently, we introduced a way for SimpleSAMLphp to coexist with applications using PHP sessions at the same time as SSP, forcing it to save the application’s session and avoiding both sessions to interfere with each other. This is done by getting all the parameters of the other session, and saving them to be able to restore it later. That existing session is closed (removed from the environment and committed to the session backend) by calling session_write_close(), which is the method throwing the exception in your case. So PHP is complaining about a session ID that’s invalid, and the point at which it is complaining is when SimpleSAMLphp is trying to save an existing, external session.

Since these changes were introduced in version 1.14.5, it makes full sense that you are seeing the issue after upgrading to 1.14.5 or later. That doesn’t mean though this is an issue in SimpleSAMLphp. On the contrary, it seems it’s an issue in your setup, that didn’t show up before just because prior to 1.14.5, SimpleSAMLphp did not bother to try to save the applications session.

I’d review the configuration and the general architecture of your system. Also, tracing the HTTP exchange with something like the SAML tracer would help. If you see a cookie with the same name as your SimpleSAMLphp session cookie being set (the "Set-Cookie" HTTP header), prepended with an underscore, take a look at the URI that originated that cookie being set. That’s probably the source of your trouble.

[Robert Wolf]

Dear Jaime,

thank you for your response.

On Fri, 5 Aug 2016, Jaime Perez Crespo wrote:

> > Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] SimpleSAML_Error_Exception: Error 2 - Unknown: The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,'
> > Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] Backtrace:
> > Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] 1 /var/lib/simplesamlphp/instances/simplesamlphp-abadms/www/_include.php:83 (SimpleSAML_error_handler)
> > Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] 0 [builtin] (N/A)
> > Aug 3 10:58:49 servername simplesamlphp[9029]: 3 [55f0db324c] SimpleSAML_Error_Exception: Error 2 - Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5/sessions)
>
> This is likely to be an issue. Have you verified that your web server can write new files to that path?

*** I think, the webserver can write to this location:

drwx-wx-wt 2 root root 12288 Aug 8 16:03 /var/lib/php5/sessions/

and there are many sess_* files, but the IDs are shorter then what I found in
SimpleSAML\Utils\Random::generateID():

-rw------- 1 www-data www-data 3652 Aug 8 16:02 sess_f7c2a7237eb5795e971a34cb733283e8
-rw------- 1 www-data www-data 3652 Aug 8 16:02 sess_fd7c68e90c060864641b859c7fd97006
-rw------- 1 www-data www-data 3652 Aug 8 16:02 sess_fe0f6824b67c03fc34a48645169b8c33
-rw------- 1 www-data www-data 3652 Aug 8 16:02 sess_ff2298b9211fe47ccbcff0116e2719f7

> > The PHP5 checks if the session ID contains only allowed characters, but since
> > SSP 1.14.5 the function SimpleSAML_SessionHandlerPHP::setCookie() sets to PHP
> > Session ID (using session_id() function) to own random generated ID from
> > SimpleSAML\Utils\Random::generateID(), which begins with "_”.
>
> No, it doesn’t. This is the method that generates an ID for the session, the
> one that setCookie() is setting latter on by calling session_id():
>
>
> /**
> * Create a new session id.
> *
> * @return string The new session id.
> */
> public function newSessionId()
> {
> // generate new (secure) session id
> $sessionId = bin2hex(openssl_random_pseudo_bytes(16));
> SimpleSAML_Session::createSession($sessionId);
>
> return $sessionId;
> }

*** OK, I have found this method in SessionHandlerPHP.php and
SessionHandlerCookie.php, which calls createSession() from Session.php and
this createSession() uses the $sessionId in PHP array:

self::$sessions[$sessionId] = null;


But I mean code from www/authmemcookie.php

--------------------------------------------------
33 // generate session id and save it in a cookie
34 $sessionID = SimpleSAML\Utils\Random::generateID();
35
36 $cookieName = $amc->getCookieName();
37
38 $sessionHandler = SimpleSAML_SessionHandler::getSessionHandler();
39 $sessionHandler->setCookie($cookieName, $sessionID);
--------------------------------------------------

$sessionID is generated in SimpleSAML\Utils\Random::generateID() and then is
called $sessionHandler->setCookie($cookieName, $sessionID) and this sets PHP
Session ID in SessionHandlerPHP.php:

--------------------------------------------------
346 if (session_id() !== '') {
347 // session already started, close it
348 session_write_close();
349 }
350
351 session_id($sessionID);
352 $this->sessionStart();
--------------------------------------------------

At least, if I have inserted some debug outputs before line 351 and after 351
to write the PHP Session ID direct from PHP using session_id(), then before
351 it writes shorter PHP-valid PHP session ID and after 351 it writes longer
PHP-invalid PHP session ID with "_" at the beginning:

--------------------------------------------------
346 if (session_id() !== '') {
347 // session already started, close it
348 session_write_close();
349 }
350
351 if ($f=fopen("php://stderr","w")) { fwrite($f,sprintf("before Session ID:%s\n",session_id())); fclose($f); };
352 session_id($sessionID);
353 if ($f=fopen("php://stderr","w")) { fwrite($f,sprintf("after Session ID:%s\n",session_id())); fclose($f); };
354 $this->sessionStart();
--------------------------------------------------


Generates following output in the error log (apache2/error.log):

--------------------------------------------------
before Session ID:
after Session ID:a29ed02d990b010739a789feaf1d4ac9
before Session ID:a29ed02d990b010739a789feaf1d4ac9
after Session ID:_8e109d2d0e8028d01e46810505a3c189939b44ccb9
[Mon Aug 08 16:30:10.682702 2016] [:error] [pid 9356] [client 127.0.0.1:37270] PHP Warning: Unknown: The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in Unknown on line 0, referer: https://IDP-SERVER/module.php/core/loginuserpass.php?AuthState=_aa7458296a1b2174d06550dc66a7fe8bc8c9b5d8b0%3Ahttps%3A%2F%2FIDP-SERVER%2Fsaml2%2Fidp%2FSSOService.php%3Fspentityid%3DSP-SERVER%26cookieTime%3D1470666583%26RelayState%3Dhttps%253A%252F%252FSP-SERVER%252Fauth%252Fauthmemcookie.php
[Mon Aug 08 16:30:10.684209 2016] [:error] [pid 9356] [client 127.0.0.1:37270] PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5/sessions) in Unknown on line 0, referer: https://IDP-SERVER/module.php/core/loginuserpass.php?AuthState=_aa7458296a1b2174d06550dc66a7fe8bc8c9b5d8b0%3Ahttps%3A%2F%2FIDP-SERVER%2Fsaml2%2Fidp%2FSSOService.php%3Fspentityid%3DSP-SERVER%26cookieTime%3D1470666583%26RelayState%3Dhttps%253A%252F%252FSP-SERVER%252Fauth%252Fauthmemcookie.php
--------------------------------------------------

The first "before Session ID" is empty while this is first access to this
site, then first "after Session ID" shows PHP-valid PHP generated session ID.

The second "before Session ID" shows still PHP-valid PHP session ID, but then the
code sets PHP-invalid PHP sessions ID.

And thea PHP session file for PHP-valid session ID does exist in the
/var/lib/php5/sessions:

-rw------- 1 www-data www-data 3652 Aug 8 16:30 sess_a29ed02d990b010739a789feaf1d4ac9


If I replace the underscore in generateID() with "a", then I can see
following output in apache2/error.log

--------------------------------------------------
before Session ID:
after Session ID:6086b10babf284f3c82e961dd318a415
before Session ID:6086b10babf284f3c82e961dd318a415
after Session ID:a135885e6eddfde6c0a9e7d569f4ae0f3f24b0c49eb
--------------------------------------------------

There is no error about invalid session id and about writing to
/var/lib/php5/sessions. So the session ID comes really from generateID() and
not from newSessionId().

And there exist the PHP session files too for both session IDs in
/var/lib/php5/sessions:

--------------------------------------------------
-rw------- 1 www-data www-data 3652 Aug 8 17:04 sess_6086b10babf284f3c82e961dd318a415
-rw------- 1 www-data www-data 3751 Aug 8 17:04 sess_a135885e6eddfde6c0a9e7d569f4ae0f3f24b0c49eb
--------------------------------------------------

> Well, if this was an issue as you are describing it, SimpleSAMLphp would be
> unusable with PHP sessions. I find it unlikely then that nobody mentioned
> this so far, if that was the case. Furthermore, I’ve tested these last
> releases extensively with both the PHP and Memcache session handlers, since
> there were a lot of changes there fixing bugs, and they work just fine. I
> have just verified indeed that the session IDs generated do not contain any
> underscores and that sessions work fine when PHP is managing them.

*** We use the "Auth MemCookie" with Apache "Auth MemCookie" Module as
described in "SimpleSAMLphp Advanced Features" / "Auth MemCookie":

https://simplesamlphp.org/docs/1.14/simplesamlphp-advancedfeatures#section_5

Is this maybe unsupport now? Should we use some other solution?

> My guess is that you have some collision with the session cookie between
> SimpleSAMLphp and some other application, causing trouble to SimpleSAMLphp.

*** There is no other application. Original apache on debian installation,
with "It works!" default static HTML page, whole <Location /> protected with:

Alias /auth /var/lib/simplesamlphp/instances/simplesamlphp-sso-test/www
<Location /auth>
Order allow,deny
allow from all
Satisfy any
</Location>

<Location />
Auth_memCookie_CookieName SimpleSAMLSessionID
Auth_memCookie_Memcached_Configuration "--SERVER=127.0.0.1:11211"
Auth_memCookie_SessionTableSize 20
Auth_memCookie_Authoritative on
Auth_memCookie_SetSessionHTTPHeader on
ErrorDocument 401 "/auth/authmemcookie.php"
AuthType Cookie
AuthName "My Login"
require valid-user
</Location>

Is this configuration still correct?

> Since these changes were introduced in version 1.14.5, it makes full sense
> that you are seeing the issue after upgrading to 1.14.5 or later. That
> doesn’t mean though this is an issue in SimpleSAMLphp. On the contrary, it
> seems it’s an issue in your setup, that didn’t show up before just because
> prior to 1.14.5, SimpleSAMLphp did not bother to try to save the
> applications session.
>
> I’d review the configuration and the general architecture of your system.
> Also, tracing the HTTP exchange with something like the SAML tracer would
> help. If you see a cookie with the same name as your SimpleSAMLphp session
> cookie being set (the "Set-Cookie" HTTP header), prepended with an
> underscore, take a look at the URI that originated that cookie being set.
> That’s probably the source of your trouble.

*** As the sso-test host does not use any PHP application using PHP sessions,
the only possibility is www/authmemcookie.php. As written above, is some
problem in the www/authmemcookie.php code? Should be this this updated
somehow?


May I show you the browser path? Does it help?

First access to SP:

>>> URL=https://sso-test.DOMAIN/
<<< Set-Cookie=PHPSESSID=a4b360700531b2f918b2d32f14653b2b; path=/

This PHPSESSID cookie is set in requireAuth() from www/authmemcookie.php:

--------------------------------------------------
24 // load Auth MemCookie configuration
25 $amc = SimpleSAML_AuthMemCookie::getInstance();
26
27 $sourceId = $amc->getAuthSource();
28 $s = new SimpleSAML_Auth_Simple($sourceId);
29
30 // check if the user is authorized. We attempt to authenticate the user if not
31 $s->requireAuth();
--------------------------------------------------


and then it redirects to SSO.

After successfull login SSO redirects to SP:

>>> URL=https://sso-test.DOMAIN/auth/module.php/saml/sp/saml2-acs.php/sso-test.DOMAIN-sp
>>> Cookie
>>> PHPSESSID=a4b360700531b2f918b2d32f14653b2b
<<< Set-Cookie
<<< PHPSESSID=a4b360700531b2f918b2d32f14653b2b; path=/
<<< SimpleSAMLAuthToken=a2d30d65fd2135d097b380a246386b71dd492b02df4; path=/
<<< Location=https://sso-test.DOMAIN/auth/authmemcookie.php

saml2-acs.php redirects to authmemcookie.php again with two PHPSESSID:

>>> URL=https://sso-test.DOMAIN/auth/authmemcookie.php
>>> Cookie
>>> PHPSESSID=a4b360700531b2f918b2d32f14653b2b
>>> SimpleSAMLAuthToken=a2d30d65fd2135d097b380a246386b71dd492b02df4
<<< Set-Cookie
<<< PHPSESSID=a4b360700531b2f918b2d32f14653b2b; path=/
<<< PHPSESSID=a72dee9c023ff0c11653ca07ac6f771c2ab78e1d81e; path=/
<<< Location=https://sso-test.DOMAIN/auth/authmemcookie.php

The second PHPSESSID is set in setCookie() in www/authmemcookie.php:

--------------------------------------------------
38 $sessionHandler = SimpleSAML_SessionHandler::getSessionHandler();
39 $sessionHandler->setCookie($cookieName, $sessionID);
--------------------------------------------------

and then it redirects again to authmemcookie.php:

>>> URL=https://sso-test.DOMAIN/auth/authmemcookie.php
>>> Cookie
>>> PHPSESSID=a72dee9c023ff0c11653ca07ac6f771c2ab78e1d81e
>>> SimpleSAMLAuthToken=a2d30d65fd2135d097b380a246386b71dd492b02df4
<<< Set-Cookie
<<< PHPSESSID=a72dee9c023ff0c11653ca07ac6f771c2ab78e1d81e; path=/
<<< PHPSESSID=a535fcd4fe2beaa36ade7819a075b37c2ffaa53c153; path=/
<<< Location=https://sso-test.DOMAIN/auth/authmemcookie.php

and again and again, everytime setting new ID for PHPSESSID:

>>> URL=https://sso-test.DOMAIN/auth/authmemcookie.php
>>> Cookie
>>> PHPSESSID=a535fcd4fe2beaa36ade7819a075b37c2ffaa53c153
>>> SimpleSAMLAuthToken=a2d30d65fd2135d097b380a246386b71dd492b02df4
<<< Set-Cookie
<<< PHPSESSID=a535fcd4fe2beaa36ade7819a075b37c2ffaa53c153; path=/
<<< PHPSESSID=a1f6142cff647aedc9e5bf6754ba58aef767a52326e; path=/
<<< Location=https://sso-test.DOMAIN/auth/authmemcookie.php

>>> URL=https://sso-test.DOMAIN/auth/authmemcookie.php
>>> Cookie
>>> PHPSESSID=a1f6142cff647aedc9e5bf6754ba58aef767a52326e
>>> SimpleSAMLAuthToken=a2d30d65fd2135d097b380a246386b71dd492b02df4
<<< Set-Cookie
<<< PHPSESSID=a1f6142cff647aedc9e5bf6754ba58aef767a52326e; path=/
<<< PHPSESSID=a43e6c16b0e39b558a2315f759d861c183be4558965; path=/
<<< Location=https://sso-test.DOMAIN/auth/authmemcookie.php



Do you have any idea? I am not sure, how it should works. Should it really set
other PHPSESSID oder should it use some other Cookie for SSP Session?


Thank you very much for your help. I will try to search myself, what could be
the error, if we have some problem in config.


Regards,

Robert Wolf.

[Jaime Perez Crespo]

Hi Robert,

Sorry for the delay, and thanks a lot for your detailed email! It really makes things much easier when we have such amount of information :-)

On 08 Aug 2016, at 18:17 PM, Robert Wolf <r.wol...@atlas.cz> wrote:
> But I mean code from www/authmemcookie.php
>
> --------------------------------------------------
> 33 // generate session id and save it in a cookie
> 34 $sessionID = SimpleSAML\Utils\Random::generateID();
> 35
> 36 $cookieName = $amc->getCookieName();
> 37
> 38 $sessionHandler = SimpleSAML_SessionHandler::getSessionHandler();
> 39 $sessionHandler->setCookie($cookieName, $sessionID);
> --------------------------------------------------

That’s a bug. It should use SimpleSAML\Utils\HTTP::setCookie(), not the method in the session handler, which is intended only to set the session cookie. And actually, I see the same bug in other places.

Would you mind applying the attached patch and tell me if it solves the issue for you? The patch was generated against master, but I believe it should apply smooth against the latest stable release.

Thanks!

[Robert Wolf]

Hello Jaime,

> Sorry for the delay, and thanks a lot for your detailed email! It really
> makes things much easier when we have such amount of information :-)

*** No problem, I was only afraid that this problem is some mistake on my
installation and you don't want to search the problem anymore:-)

> That’s a bug. It should use SimpleSAML\Utils\HTTP::setCookie(), not the
> method in the session handler, which is intended only to set the session
> cookie. And actually, I see the same bug in other places.
>
> Would you mind applying the attached patch and tell me if it solves the issue
> for you? The patch was generated against master, but I believe it should
> apply smooth against the latest stable release.

*** I have applied successfully this patch with offset -2.

Now, there is no error in php session ID, but there is one another problem.
After successful IdP login the browser is redirected to

https://sso-test.DOMAIN/auth/module.php/saml/sp/saml2-acs.php/sso-test.DOMAIN-sp

and then to

https://sso-test.DOMAIN/auth/authmemcookie.php

and this redirects back to authmemcookie.php again and again until browser
fails with "The page isn’t redirecting properly".

I have configured the SP server with old SSP version (1.14.4) and after IdP
login and redirect to saml2-acs.php the browser is redirected to original
address.

The problem is probably somewhere in the first redirect to IdP.

On the server with old SSP version, if I go to URL

https://server.domain/page

the SSP generates response with redirect to

https://sso.domain/saml2/idp/SSOService.php?SAMLRequest=....&RelayState=https://server.domain/page


But if I go to https://sso-test.DOMAIN/index.html, SSP 1.14.7 generates
redirect to

https://sso.domain/saml2/idp/SSOService.php?SAMLRequest=....&RelayState=https://sso-test.DOMAIN/auth/authmemcookie.php



I have now traced the problem to lib/SimpleSAML/Utils/HTTP.php, function
getSelfURL().

Script authmemcookie.php calls SimpleSAML_Auth_Simple::requireAuth() on line
31 without any parameters. From SimpleSAML_Auth_Simple::requireAuth() is
called SimpleSAML_Auth_Simple::login($params) on line 83, where $params is empty. This
calls SimpleSAML_Auth_Source::initLogin() on line 141 with $returnTo variable,
which is generated in lib/SimpleSAML/Auth/Simple.php between lines 112 and
122. In my case, the $returnTo URL is generated from
\SimpleSAML\Utils\HTTP::getSelfURL() on line 117.

backtrace:simplesamlphp/www/authmemcookie.php:31:requireAuth()
backtrace:simplesamlphp/lib/SimpleSAML/Auth/Simple.php:83:login()
backtrace:simplesamlphp/lib/SimpleSAML/Auth/Simple.php:141:initLogin()

And this function is since 1.14.5 and later different than in 1.14.4. In 1.14.4
it generates the original accessed page, in 1.14.7 generates the URL for the
authmemcookie.php script, i.e. https://sso-test.DOMAIN/auth/authmemcookie.php.

I am not sure, how it should really work. Do I miss somewhere to set returnTo
option to original entered URL? Maybe in authmemcookie.php set ReturnTo to
following value?

getSelfURLHost().$_SERVER["REQUEST_URI"]

But even if I set

$s->requireAuth(array("ReturnTo"=>\SimpleSAML\Utils\HTTP::getSelfURLHost().$_SERVER["REQUEST_URI"]));

in authmemcookie.php, the browser comes to saml2-acs.php and from here
redirects to https://sso-test.DOMAIN/index.html, but it redirects again to
/auth/authmemcookie.php and makes infinite redirects and browser displays error

"The page isn’t redirecting properly".

But if I now enter the URL https://sso-test.DOMAIN/index.html again, then the
page is displayed without redirecting. So the SAML login works and I have valid
SAML session, but there is something wrong to get back to original page from
SAML SP pages.


I have no idea anymore. Can you see the problem?


Thank you very much for support.

Regards,

Robert Wolf.