Its caused by the default config of the STS wizard, when making an IDP SSO project. Its metadata has entity name equal to the registered audience (an http uri...), but the web.config uses a different value whe nconfiguring how the issuer field is treated,
by the code controlling assertion content. THus ACS objects... (is my best guess) to assertions that do not tie to the registered entityID of the metadata for said IDP.
If you change the web.config issuer application parameter to have the same values as the entityID of the IDPs metadata, the problem goes away.
I also had to remove the signature from the signed metadata, for ACS to accept it. Ill guess that it may be possible to first upload a cert to ACS, that will verify the signed metadata (and the cert that said stream bears) subsequently assigned to an new
IDP entry of ws-fedp type.
if someone has power... have visual studio 2011 template for claimsaware sites change how the STS wizard works, so the generated STS code does NOT not cause all this!
I forgot another default STS site (built by STS wizard) to Azure ACS interworking issue.
One must change how the scope.Audience is assigned in the STS callback GetScope(). Audience must be assigned the value of the request.ReplyTo - so that it the response bearing asserting is sent to the correct assertion consuming service endpoint path (and
not to the default path of the namespace, which is what happens currently... inducing failure).