SimpleSAML installation and usage can be tricky, and when set up incorrectly it can cause a number of problems.
The first step in troubleshooting is to turn on debugging. Edit the
config.php file and set
TRUE then set
LOG_DEBUG. The logs will be written to
php-errors.log in the normal log location may be helpful too if there is a misconfiguration or typo in any of the config files that is causing a php error.
Often, you can look in the kvstore table to figure out what SimpleSAMLphp has actually done with the request it’s parsed out, and that’s always stored in there. Be sure to check the SAMLSession cookie, because you’ll need it to check in the kvstore table.
Working with Error Messages
SAML can present a number of errors, with different causes and solutions.
- StatusCode - urn:oasis:names:tc:SAML:2.0:status:Requester
This usually means that there is a configuration problem on the SP’s part, but the IdP isn’t providing any more information as part of that request. Ask the IdP for their logs regarding the request so you can start to determine what is misconfigured.
- Missing Attributes
Sometimes, the IdP won’t send back the attributes required to identify the user. This is usually caused by a misconfiguration on the IdP side of things. Typically this will present itself as a 500 error a record in watchdog.
The SAMLSession cookie will be present in an authenticated user’s session, which you can then use to go look up the session information in SimplesSAMLphp’s
kvstoretable. Once you deserialize it, you can go look to see if the attributes are in there. If not, you’ll need to discuss with the IdP to determine why they aren’t sending them.
- Attributes with a missing FriendlyName parameter
This could be the case when there are attributes coming, but they don’t have the
FriendlyNameparameter. You can determine this in the same way you'd figure out if another parameter was missing (see previous bullet.) To fix this, configure the Simplesamlphp_Auth module’s configuration settings to be the absolute name of the parameter, which is a urn that should never change.
- Page caching breaks custom login flow
You can see this if you're using IdP initiated SSO, and expecting any page to pick up the SAML login flow. Basically, SimpleSAMLphp_auth uses
hook_initto do a lot of set up work (this needs to change), and if Drupal page cache is enabled it won’t work.
- The Certificate File could not be loaded
When you see an error like this, the configuration is usually in the wrong file, or the config variable is pointing to the wrong file. There is also the possibility that
redirect.signis not set and the IdP is expecting a signed request or it’s sending back a signed request.