The following errors are commonly encountered by users, usually when initially setting up their SP.
opensaml::SecurityPolicyException: Message expired, was issued too long ago.
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 MUST maintain accurate time. Refer to your OS documentation for information on how to synchronize with a reliable time source.
Message was signed, but signature could not be verified.
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:
- The certificate in the metadata is different from the one configured for the IdP, and hence, the one in the message. For a Shibboleth IdP that would be
relying-party.xml, You should change them so they match..
- If PKIX(CN matching with a signed root) is being used, the CN of the certificate used to sign the message is not the same as the CN expected by the KeyName of that provider's metadata.
- The IdP is using the wrong entityID and mistakenly trying to spoof another IdP.
Unable to establish security of incoming assertion
This error will be presented in the browser for a variety of different underlying reasons. Check
shibd.log for more useful debugging information
Unable to locate metadata for identity provider
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.
- Check that the entityID is correct, and names the identity provider you intend to speak to.
- Make sure you're loading the metadata of that identity provider.
- Make sure that the identity provider's metadata contains everything good IdP metadata does.
- If the problem occurs with a IdP which previously worked with this SP, then the issue may be that the metadata has expired.
HTTP POST form data is lost when Shibboleth session expired or does not exist yet
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 can be configured to preserve HTTP POST data:
- In the
<Sessions>element of the
shibboleth2.xmlconfiguration file add the attributes '
where <id> is the id value of the <Storage> element. The default will be to add '
'postTemplate="postTemplate.html"'that points to the default HTML file to use when resubmitting the HTTP POST request.
shibboleth2.xmland restart the
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
postExpire on Sessions.
SAML message delivered with POST to incorrect server URL.
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.
- Verify that the server name and port are properly set in accordance with the SP's metadata.
- Rewriting rules in effect for the
Shibboleth.ssohandler path must be consistent with the SP's metadata.
- The IdP needs to properly address the SAML response.
opensaml::saml2md::MetadataException: Security of SAML 1.x SSO POST response not established.
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
opensaml::FatalProfileException: A valid authentication statement was not found in the incoming message.
Non-specific. You need to check the log for specific information about why the incoming assertion was invalid.
supplied TrustEngine failed to validate SSL/TLS server certificate
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".
Unable to resolve any key decryption keys
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).
ERROR Shibboleth.AttributeResolver : exception during SAML query to <url>: CURLSOAPTransport failed while contacting SOAP responder: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
ERROR Shibboleth.AttributeResolver.Query : exception during SAML query to <url>: CURLSOAPTransport failed while contacting SOAP endpoint (<url>): error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
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.
If it is supported, the best solution is to run the IdP without Apache which is the recommended way of deploying IdP V3.
Can't connect to listener process
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.
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
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
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>.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
.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 processissue, even when restarting SELinux in enforcing mode once again.
Compile and install the policy file with: