simplesamlphp-nostate.md

Debugging "State Information Lost" errors

"State Information Lost" (SimpleSAML_Error_NoState: NOSTATE)

This is one of the most common errors that you can encounter when configuring SimpleSAMLphp. Unfortunately, it is also a generic error that can have many possible causes. This document will attempt to describe what this error actually means, and some of the situations that can cause it.

What is "state information"?

The "state information" is data that SimpleSAMLphp stores in association with a request. The request is typically a SAML 2.0 authentication request sent to the IdP, but it can also be other requests.

This state information is given a random ID, e.g. "_2da56e07840b59191d9797442b6b665d67d855cf77", and is saved in the session of the user.

What does it mean that it was lost?

This means that we tried to load state information with a specified ID, but were unable to find it in the session of the user.

What can cause it to be lost?

There are several ways that this can happen, but most of them have to do with session storage. Here we will outline some generic alternatives, and possible solutions.

The domain name changed during authentication

The domain name the IdP sends the response to is configured in the metadata of the IdP. This means that it may not match up with the domain name the user accessed. For example we may have the following scenario:

1. The user accesses https://www.example.org/. A session is created for the user, and the session cookie is set for the current domain (www.example.org).
2. The user needs to be authenticated. We therefore save some information about the current status in the state array, create a SAML 2.0 authentication request, and send it to the IdP.
3. The user logs in on the IdP. The IdP then sends a response to the SP at example.org. However, the metadata for the SP that is registered at the IdP uses https://example.org/ (without www) as the domain the response should be sent to. The authentication response is therefore sent to that domain.
4. The SP (now at https://example.org/) tries to load the state information associated with the authentication response it received. But, because the domain name has changed, we do not receive the session cookie of the user. We are therefore unable to find the session of the user. When we attempt to load the state information from the session we are therefore unable to find it.

There are several ways to solve this. One of the simplest is often to configure your webserver to only use one domain, and redirect all accesses to the other domain to the correct domain.

A different solution is to change the session cookie settings, so that they are set for the "example.org" domain. If you are using PHP sessions, you should change this in php.ini. If not, you should change it with the 'session.cookie.domain' option in config/config.php. In either case, it should be set to the top-level domain with a "dot" in front of it. E.g.:

'session.cookie.domain' => '.example.org',

Or in php.ini:

session.cookie_domain = ".example.org"

Note that if you use PHP sessions, you will also have to make sure that your application uses the same domain when it sets the cookie. How that is done depends on your application. (See the section about mismatch between application PHP session settings and SimpleSAMLphp session settings.)

Hopping between http and https