Failure to validate Response Signature

[Rainer Hoerbe]

I browsed again thru the logs once more to find a potential hints, and compared the entityIDs and certificates to make sure that there is no typo.

These are the log messages after the Response was decoded:
OpenSAML.MessageDecoder.SAML2 [2]: extracting issuer from SAML 2.0 protocol message
OpenSAML.MessageDecoder.SAML2 [2]: message from (https://apps.egiz.gv.at/moa-id-stork-test/)
OpenSAML.MessageDecoder.SAML2 [2]: searching metadata for message issuer...
OpenSAML.SecurityPolicyRule.MessageFlow [2]: evaluating message flow policy (replay checking on, expiration 60)
XMLTooling.StorageService [2]: inserted record (_eb6...) in context (MessageFlow) with expiration ..
OpenSAML.SecurityPolicyRule.XMLSigning [2]: validating signature profile
XMLTooling.KeyInfoResolver.Inline [2]: resolved 0 certificate(s)
XMLTooling.KeyInfoResolver.Inline [2]: resolved 0 CRL(s)
XMLTooling.TrustEngine.ExplicitKey [2]: attempting to validate signature with the peer's credentials
XMLTooling.TrustEngine.ExplicitKey [2]: public key did not validate signature: Credential did not contain a verification key.

So it seems not that the keys are not matching, but the TrustEngin does not receive keys from either md or response.

What could be done to trace this?

> No, actually it compares the keys. The actual steps are:
> 
> - ask the metadata plugin to give it all of the valid keys it can return
> for that issuer
So "verification key is one of the list from 
//EntityDescriptor[...]//KeyDescriptor//X509Certificate
> - try the resulting keys in sequence to verify the signature
so "credential" is synonym with the public key extracted from
//saml2p:Response/ds:Signature/KeyInfo/X509Data/X509Certificate?

> 
> But in the first step, it uses the key from the KeyInfo in the message as
> an input to the lookup process in the metadata. So what it does is say to
> return only keys that "match" that criteria, which in the case of a public
> key means "return a key only if it matches the input key exactly".
> 
> So in this case, either they don't really match, or some other criteria
> for matching is getting in the way, and short of key names, I don't know
> what that would be. If the certificates match exactly, there'd be no
> explanation I can think of. I don't recall any cases in which something
> like that has been reported and it hasn't turned out to be something
> unrelated, usually the metadata not being what was assumed.
> 
> -- Scott
- Rainer