Shibboleth 3 SAML Response Debugging

[McKean, Brandon Scott - mckeanbs]

I'm equally baffled at this point. I did another test with the v2 IDP
against testshib, and it produces an identical result at this point.
However as far as testshib is concerned, both IDPs give it information
without error.
Since the metadata still referred to SAML1, and most of our providers
are using that rather than SAML2, I tried chopping out all SAML2
references from metadata and giving testshib that, to try to force it
to use that instead.
The results are particularly enlightening. While it still passes, the
shibd.log results are a lot different. It seems that it tries to make a
connection to the production Shibboleth at a different IP:
015-07-16 11:54:05 DEBUG XMLTooling.SOAPTransport.CURL [73]: sending
SOAP message to https://itfederation.jmu.edu:8443/shibboleth-idp/AA
2015-07-16 11:54:05 DEBUG XMLTooling.libcurl [73]:   Trying
134.126.10.44...

2015-07-16 11:54:05 DEBUG XMLTooling.libcurl [73]: Connected to
itfederation.jmu.edu (134.126.10.44) port 8443 (#0)
Then...
2015-07-16 11:54:05 ERROR OpenSAML.SOAPClient [73]: SOAP client detected a SAML error: (saml1p:Responder) (Error resolving principal)
2015-07-16 11:54:05 ERROR Shibboleth.AttributeResolver.Query [73]: attribute authority returned a SAML error
That might explain why it's failing, I had assumed I could fully test it with host file edits. Would this explain anything?
Thanks,
Brandon
On Thu, 2015-07-16 at 15:30 +0000, Cantor, Scott wrote:
> On 7/16/15, 11:21 AM, "users on behalf of McKean, Brandon Scott -
> mckeanbs" <users-bounces at shibboleth.net on behalf of mckeanbs at jmu.edu
> > wrote:
> 
> > Hmm, I think I might have more information now, from testshib's
> > log.
> 
> The signature was fine, but the encryption was performed under the
> wrong key. In this case, you would have to have the wrong metadata
> for testshib, I guess.
> 
> That assumes testshib actually reported a failure. Nothing in that
> log was a definitive end result of anything.
> 
> > This would reinforce what you said before about it being a
> > credential issue, but I'm not sure where that would be breaking
> > down. The openssl commands I did before verified idp-signing.key
> > and idp-signing.crt matched, and they are set as such in
> > idp.properties.
> 
> It evaluated your key just fine.
> 
> I am at this point lost as to who's failing, what's failing, and what
> the logs actually say because you've posted contradictory outcomes.
> 
> -- Scott
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150716/3d997eed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5673 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20150716/3d997eed/attachment.bin>