Common Shibboleth SP errors encountered
Barring an actual replay attack, your SP's clock isn't synchronized with the clock of the IdP that issued the message. All servers using SAML <strong>MUST</strong> maintain accurate time. Refer to your OS documentation for information on how to synchronize with a reliable time source.
The certificate that was used to sign the message didn't match the one the SP expected based on metadata. That can be caused by, in order of likelihood:
This message indicates the SP tried to initiate a session with an entityID it doesn't recognize as belonging to an identity provider. That's probably because the entityID in the SessionInitiator has no corresponding metadata loaded, but it could also happen with a discovery service that knows more than you do.
Sometimes a user submits HTTP POST data to a page that requires a valid Shibboleth session. An example could be a user that completes a web form. If the user does not have yet a valid Shibboleth session or if his session expired, he is redirected to his Identity Provider and forced to re-authenticate. Coming back to the protected page his HTTP POST data is lost due to the redirects. The following steps explain how the SP (2.2 or above required) can be configured to preserve HTTP POST data:
Using the above-mentioned settings, the SP will preserve and re-post the HTTP POST data after the user got a valid Shibboleth session. Note that this can have unintended consequences if the user clicks on the back button of his web browser. In this case the HTTP POST data might be resent again. Therefore, the application that processes the POST data should take this into account when accepting the data.
For further information, have a look at the configuration options postData, postTemplate and postExpire on NativeSPSessions.
When a SAML message is addressed to a location inconsistent with where the SP believes it's running, this error will be thrown. The SP pulls much of this information from the web environment.
The usual cause for this is an incoming SAML assertion/response from an issuer for which the SP has no metadata loaded. This means either the metadata is wrong, or the IdP in question is using the wrong entityID in its configuration, so the URI passed to the SP doesn't match what it expects.
More specific information is usually available from the shibd.log file.
Non-specific. You need to check the log for specific information about why the incoming assertion was invalid.
The IdP's metadata provides the rules for determining whether a certificate used for a signature or found at a SOAP endpoint is acceptable. This error means it wasn't acceptable. Either the metadata is wrong, or the certificate is, but they don't "match".
The SP received encrypted XML (usually an EncryptedAssertion) and couldn't decrypt it. The SP's metadata probably doesn't contain the same public key(s) the SP is configured to use (or the credentials didn't load).
Appears in shibd.log during back-channel communications. Seems to be very unpredictable, but is caused by some kind of OpenSSL bug when zlib is used to compress the SSL traffic. Particularly common on the second (and subsequent) attempts to use a cached SSL session. There doesn't seem to be a real solution to this, but a couple of bad work-arounds include:
At this time, it is not known if running with Tomcat's SSL implementation is subject to the bug, but running without Apache may be a solution for some sites.
Appears in shibd.log during back-channel communications. This indicates that one of the peers rejected the certificate of the other.
If the log includes errors mentioning a "TrustEngine" failing to verify the SSL certificate, the error indicates that the SP rejected the IdP's server certificate and the metadata is wrong or invalid in some respect.
Otherwise, this usually indicates that the IdP rejected the certificate the SP presented, but did so using a layer of code inside the Apache mod_ssl module. This happens when Apache is misconfigured by allowing mod_ssl to validate the certificate. You need to make sure the SSLVerifyClient option is set to "optional no_ca" on the IdP.
If you think it is set, you're either mistaken or the certificate violated a built-in requirement that mod_ssl refuses to disable. Sometimes this can be corrected by upgrading to a newer Apache version, but it may not be something you can fix.
You may also consider running the IdP without Apache, which is now supported and documented. Note that you can do this for back-channel communication on port 8443 while still running Apache in front of the container for front-channel support on port 443, if your authentication solution requires that Apache be used.
Appears in the browser when the server module can't communicate with shibd for some reason. The "duh" solution is to check whether it's running, but on Red Hat, another common cause is SELinux being enabled. That prevents socket communication between Apache and shibd, but doesn't really provide much feedback about it.
Feedback about the SELinux issue here can be gleaned by running SELinux in permissive mode - the default is enforcing.
What you will find, from running audit2allow for an initial httpd+shibd setup, is that you simply need a policy that permits the Apache server (httpd) to access /var/run/shibboleth/shibd.sock
Such a module can be created, once you have logged the problem by running SELinux in
permissive mode, by running the command:
after which you will have generated a <name_of_module>.te and <name_of_module>.pp file, the latter being the compiled module,
along with instructions on how to load the module into the SELinux regime.
Simply giving the httpd server access to /var/run/shibboleth/shibd.sock should merely require a .te file that looks like this:
Your .te file may obviously contain extra defintions and rules depending upon what your local httpd is trying to access, however, if the above info is in there, then that should cure the Can't connect to listener process issue, even when restarting SELinux in enforcing mode once again.
The defintions and rules in the simplistic module as detailed above should be available in the officially supported module referenced on the Security Enhanced Linux page.