Summary

A Recipient Mismatch occurs when the SAML assertion created by the IdP is form-posted to a location other than the one that was in the shire parameter sent to the IdP originally. That URL is embedded inside the signed SAML message and the SP compares its value to the location to which the browser submits the form. If they don't match, this error occurs. It prevents attacks where the SAML assertion is intercepted and redirected to a different SP than the one it was created for.

Possible Causes and Solutions

Actual man in the middle attacks, of course.

In a working production system, this is possible, but unlikely when SSL is used. There is no fix, since this is a legitimate error.

Misconfiguration of your web server environment's hostname.

This is usually the cause. When the SP processes requests, it normally has to canonicalize the requested URL so that various decisions about how to handle it can be made accurately, no matter how the client submitted it. By this I mean that with HTTP, a client can submit the request with a Host header containing any value it wants, including an IP address, alternate hostnames, etc. This can confuse the software or lead to exposure if rules are only specified for the fully-qualified hostname.

When the form is posted, the actual URL evaluated by the SP is not necessarily the string in the form's action attribute, but the canonical name, port, and scheme, combined with the path from the form. If they don't match, this error occurs.

Usually it happens in test environments that are not being given properly working addresses or hostnames, or when load balancing is involved. You can't be sloppy while testing, you have to supply legitimate consistent values to Shibboleth and the web server. This is a web server-specific activity.

Apache uses a ServerName directive in conjunction with the UseCanonicalName flag. Additional settings may be needed when load balancing.
IIS has no equivalent feature and the /SPConfig/Implementation/ISAPI element in ShibbolethXml is used to supply canonical names/aliases/ports/etc. for each IIS site that is in use.
iPlanet generally can obtain the proper hostname from its configuration, but a default server-name property can be created in magnus.conf when initializing the nsapi_shib module.

Browser not supported