I've got a simple ASP.Net app working with a Geneva server. I'm now trying to get things working with a Shibboleth IDP.
I can choose the IDP from the list 'Select Sign In Options' and get redirected to the IDPs username and password page. Assuming I get the username and password correct I get redirected to the /FederationPassive/ page on the Geneva server which has an MSIS7012 error.

In the event log I get:

The Federation Service encountered a serious error while processing the WS-Trust request.
Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue

Additional Data
Exception details:
System.IdentityModel.Tokens.SecurityTokenException: ID4153: A Saml2SecurityToken cannot be created from the Saml2Assertion because it contains a SubjectConfirmationData which specifies an Address value. Enforcement of this value is not supported by default. To customize SubjectConfirmationData processing, extend Saml2SecurityTokenHandler and override ValidateConfirmationData.
at Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenHandler.ValidateConfirmationData(Saml2SubjectConfirmationData confirmationData)
at Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenHandler.ResolveSecurityKeys(Saml2Assertion assertion, SecurityTokenResolver resolver)
at Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenHandler.ReadToken(XmlReader reader)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenElement.get_SecurityToken()
at Microsoft.IdentityServer.SecurityTokenService.MSISSecurityTokenService.GetOnBehalfOfContext(RequestSecurityToken request, IClaimsPrincipal callerPrincipal, IClaimsPrincipal& principal, AuthenticationContext& authenticationContext)
at Microsoft.IdentityServer.SecurityTokenService.MSISSecurityTokenService.BeginGetScope(IClaimsPrincipal principal, RequestSecurityToken request, AsyncCallback callback, Object state)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.BeginIssue(IClaimsPrincipal principal, RequestSecurityToken request, AsyncCallback callback, Object state)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.WSTrustServiceContractAsyncResult.BeginRST(IClaimsPrincipal authContext, RequestSecurityToken request)
at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginCore(Message requestMessage, AsyncCallback callback, Object state, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, String requestAction, String responseAction, String trustNamespace)

Can I reconfigure things to just ignore the SubjectConfirmationData or do I need to find a way to turn it off on the Shibboleth end?

Any ideas?

Hi Scott,

You will need to turn off the Address confirmation at the Shibboleth end. AD FS 2 does not support validating this confirmation data.

Turning off the Address confirmation data at the Shibboleth end doesn't look possible, at least I couldn't find any configuration options for it. Is there really no way just go get ADFS2 to ignore additional SubjectConfirmationData.
The IdP sending addition is sending as much information as it can, the SP needs to have a way of applying a policy instead of just bombing if it can't verify a single peice of information.

Are there any examples of a working ADFS2 and Shibboleth 2.1 integration? With issues like this I'm not sure it is possible at the moment.