The IdP who sent the attributes in response to a query did not authenticate the request as coming from the SP. This could be a metadata problem at the IdP (meaning the SP's metadata is wrong), a web server configuration problem at the IdP, or a client certificate problem at the SP. Figuring out which takes a lot of log investigation, mostly at the IdP end.

The cause of the error is a SAML feature called an "Audience" condition, which allows an IdP to constrain what relying parties are supposed to accept an assertion. In Shibboleth, we eventually aligned the use of Audience to a Liberty/SAML 2.0 usage in which it carries the providerId of the SP we're issuing the assertion to.

The exception to this is when a request comes in that cannot be authenticated. This may be because metadata doesn't exist for the SP, or it may be because, in the SOAP query case, the certificate used by the SP didn't show up at the IdP or the SP didn't use one. In that case, the query is "unauthenticated", and for legacy reasons, the IdP inserts the value of the defaultRelyingParty attribute into an Audience condition.

Fixing the problem requires diagnosing the metadata or SP certificate issue. Most of the time the problem is on the IdP end and is either an Apache certificate-handling error or a problem with the metadata loaded at the IdP.

Troubleshooting Hints

On the SP side

  1. In {shib-sp-root}/shibboleth-sp/etc/shibboleth/shibd.logger, update the default log level from INFO to DEBUG
  2. Restart shibd and apache to be sure everything is on the new settings.
  3. tail -f {shib-sp-root}/var/log/shibboleth/shibd.log to watch the access logs
  4. Attempt to log in through your IdP.
  5. Examine the last SOAP call and observe the Audience that the assertion is aimed at:
    DEBUG SAML.libcurl [13] sessionGet: <soap:Envelope ...
    That is your audience string that needs to be within the <saml:Audience element within the shibboleth.xml (see shibboleth.xml.dist which will be present in your etc directory of the SP install.)