State information lost, session and cookie values changing when receiving server response

[Jim]

I've got a hosted SAML 2.0 SP connecting to a remote SAML 2.0 IdP
(Shibboleth), and the "Test authentication source" fails with a "State
information lost" error after my login is accepted by the remote IdP.

It looks like my simpleSAMLphp session identifier is changing after
the redirect, when I receive the message response from the remote IdP,
and my PHPSESSID cookie value is changing then too. Here is the
relevant debug code from the log:

DEBUG [473f4601e3] Saved state:
'_e849934117f4a24ab765f70d21710377e34c8932c4'
...
DEBUG [473f4601e3] </samlp:AuthnRequest>
DEBUG [473f4601e3] Redirect to 742 byte URL: ...
DEBUG [2fadfa3d16] Received message:
DEBUG [2fadfa3d16] <saml2p:Response ...
...
DEBUG [2fadfa3d16] Loading state:
'_e849934117f4a24ab765f70d21710377e34c8932c4'
ERROR [2fadfa3d16] Error report with id 80e583e4 generated.
DEBUG [2fadfa3d16] Template: Reading [C:\var\simplesamlphp/modules/
core/dictionaries/no_state]
DEBUG [2fadfa3d16] Template: Reading [C:\var\simplesamlphp/
dictionaries/errors]

Any ideas? I think my SP/IdP config code is correct, and I shouldn't
have any special restrictions on cookie reading/writing, other than
requiring secure connections. I've tried leaving the simpleSAMLphp
config.php session variables set to their defaults and also matching
them to their php.ini values, with the same results each time.

[Olav Morken]

Are you by any chance returning the response to a different domain than
you start the authentication from? E.g. starting it from
www.example.org, and having the AssertionConsumerService in the IdP
metadata set to example.org.

Regards,
Olav Morken
UNINETT / Feide

[Jim]

> you start the authentication from? E.g. starting it fromwww.example.org, and having the AssertionConsumerService in the IdP

> metadata set to example.org.
>
> Regards,
> Olav Morken
> UNINETT / Feide

Thanks Olav. I am pretty sure it's not changing domains. And there
is no AssertionConsumerService defined, unless that's a problem too!

-- Jim

[Peter Schober]

* Jim <jimsu...@gmail.com> [2011-11-16 01:07]:

> Thanks Olav. I am pretty sure it's not changing domains. And there
> is no AssertionConsumerService defined, unless that's a problem too!

The AssertionConsumerService URL is where the SAML assertion from IdP
is sent to at the SP. Without this nothing works and SSP generates the
necessary and correct metadata by default, which includes ACS URLs.
-peter

[Jim]

On Nov 16, 7:39 am, Peter Schober <peter.scho...@univie.ac.at> wrote:
> The AssertionConsumerService URL is where the SAML assertion from IdP
> is sent to at the SP. Without this nothing works and SSP generates the
> necessary and correct metadata by default, which includes ACS URLs.
> -peter

I end up at the following URL (domain obviously altered):

https://www.mydomain.com/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp

Which is the same domain I started on and presumably just the default
simpleSAMLphp page for testing authentication sources.

This works fine when using the guest IdP openidp.feide.no -- I see the
expected list of attributes -- but when I switch to my desired remote
IdP (Shibboleth), after I log in I get the "State information lost"
error at that same page. Do I need to specify a different
AssertionConsumerService URL just to test my IdP? If so, what would
that be, or do I have to create it?

[Jim]

Any more ideas how I can troubleshoot this problem? Like I said, I
don't see any domain changing, but I somehow lose the original session
upon receiving the response from the IdP, after the redirect.

What more can I check, within simpleSAMLphp or PHP in general?

[Olav Morken]

Since it works with OpenIdP, but not with the real IdP, my guess is
that there is a difference in the domain name or with http vs. https
somewhere. I suggest that you use a request logger for your webbrowser
to investigate the requests, and checking where and how cookies are set
and received by the server.

(If you are using Firefox you may want to test the "SAML tracer"
extension that we developed:

https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/

In addition to showing the HTTP requests and responses, it also
highlights and decodes the SAML 2.0 messages.)

[Jim]

Thanks Olav. It turns out we had "session.referer_check" set to our
domain in php.ini, which was messing with the remote IdP response
coming from a different domain. Everything works fine now that I've
reset "session.referer_check" to the default (blank) value. Problem
solved!

That looks like a useful Firefox extension too -- I will definitely
check it out.