Versions Compared

Old Version 6

changes.mady.by.user Jason Woodward

Saved on

compared with

New Version 7

changes.mady.by.user Rod Widdowson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The following errors are commonly encountered by users, usually when initially setting up their SP.

Table of Contents

opensaml::SecurityPolicyException: Message expired, was issued too long ago.

...

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:

  1. 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..

  2. 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.

  3. 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 (https://identities.supervillain.edu/idp/shibboleth).

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.

  1. Check that the entityID is correct, and names the identity provider you intend to speak to.

  2. Make sure you're loading the metadata of that identity provider.

  3. Make sure that the identity provider's metadata contains everything good IdP metadata does.

  4. 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:

  1. In the <Sessions> element of the shibboleth2.xml configuration file add the attributes 'postData="ss:<id>"'
    where <id> is the id value of the <Storage> element. The default will be to add 'postData="ss:mem"'.

  2. Add 'postTemplate="postTemplate.html"' that points to the default HTML file to use when resubmitting the HTTP POST request.

  3. Save shibboleth2.xml and restart the shibd daemon

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. 
Also note that this feature only works for POST data encoded as application/x-www-form-urlencoded, which excludes forms with file uploads.  POST requests not encoded as Content-Type application/x-www-form-urlencoded will be silently converted into GET requests, and the body data dropped. A note will be made in the logs, depending on log level, but the end user will not be notified. This could be confusing to the end user and therefore might necessitate web application level changes to improve the user's experience.
For further information, have a look at the configuration options postData, postTemplate and postExpire on Sessions. 

...

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.

  1. Verify that the server name and port are properly set in accordance with the SP's metadata.

  2. Rewriting rules in effect for the Shibboleth.sso handler path must be consistent with the SP's metadata.

  3. The IdP needs to properly address the SAML response.

opensaml::saml2md::MetadataException: Security of SAML 1.x SSO POST response not established.

...