Shibboleth 3 SAML Response Debugging

[McKean, Brandon Scott - mckeanbs]

> But I don't know what result you're talking about. Nothing you posted
> provided that information except for one case which was almost
> certainly a signature failure, and which was not what you just posted
> today.
Sorry for the confusion there. What I meant there is that testshib said
the, "This page is protected by the TestShib Service Provider. If
you're reading this, your IdP successfully provided authentication
information. If you have data about you and an assertion below, then
your IdP also released attribute and authorization information." page.
This was before forcing SAML1, as I mentioned.
> Unless you push attributes, there's no way you can test that from a
> second server without touching the SPs.
> You can't do that while relying on the back channel for attributes.
> If you're still on SAML 1 for a majority of services, there is
> essentially *no way* to test it with SPs you don't control except by
> pushing attributes.
Thanks much for the clarification. In that case I can give it a shot
during our testing window when I'm able to change IPs and names around.
> It does a query to whatever endpoint's in the metadata it has.
Relative to the SP, then? That is, the SP resolves the domain how it
normally would resolve names itself, and has nothing to do with the
client using the service.
I hope this clarifies what I meant, sorry for the profound confusion, I
wasn't being very clear.
Brandon
On Thu, 2015-07-16 at 16:14 +0000, Cantor, Scott wrote:
> On 7/16/15, 12:00 PM, "users on behalf of McKean, Brandon Scott -
> mckeanbs" <users-bounces at shibboleth.net on behalf of mckeanbs at jmu.edu
> > wrote:
> 
> > 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.
> 
> But I don't know what result you're talking about. Nothing you posted
> provided that information except for one case which was almost
> certainly a signature failure, and which was not what you just posted
> today.
> 
> > 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.
> 
> Unless you push attributes, there's no way you can test that from a
> second server without touching the SPs.
> 
> > 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:
> 
> It does a query to whatever endpoint's in the metadata it has.
> 
> > That might explain why it's failing, I had assumed I could fully
> > test it with host file edits.
> 
> You can't do that while relying on the back channel for attributes.
> If you're still on SAML 1 for a majority of services, there is
> essentially *no way* to test it with SPs you don't control except by
> pushing attributes.
> 
> > Would this explain anything?
> 
> I can't correlate "it doesn't work" to a cause. I need specifics.
> 
> A failure to get attributes will result, most of the time, in a
> successful login to an SP with no data. Beyond that, it's entirely
> dependent on the deployment of the SP what happens.
> 
> -- Scott
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150716/a2fa6ae9/attachment-0001.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/a2fa6ae9/attachment-0001.bin>