Versions Compared

Key

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

...

  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.

...

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

...

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.

...

SELinux

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.

...