<html><head></head><body><blockquote type="cite"><div>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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>This was before forcing SAML1, as I mentioned.</div><div><br></div><blockquote type="cite"><div>Unless you push attributes, there's no way you can test that from a second server without touching the SPs.</div></blockquote><div><br></div><blockquote type="cite"><div>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.</div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div>It does a query to whatever endpoint's in the metadata it has.</div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"></blockquote><div><br></div><div>I hope this clarifies what I meant, sorry for the profound confusion, I wasn't being very clear.</div><div><br></div><div>Brandon</div><div><br></div><div>On Thu, 2015-07-16 at 16:14 +0000, Cantor, Scott wrote:</div><blockquote type="cite"><pre>On 7/16/15, 12:00 PM, "users on behalf of McKean, Brandon Scott - mckeanbs" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:mckeanbs@jmu.edu">mckeanbs@jmu.edu</a>> wrote:
<blockquote type="cite">
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.
</blockquote>
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.
<blockquote type="cite">
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.
</blockquote>
Unless you push attributes, there's no way you can test that from a second server without touching the SPs.
<blockquote type="cite">
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:
</blockquote>
It does a query to whatever endpoint's in the metadata it has.
<blockquote type="cite">
That might explain why it's failing, I had assumed I could fully test it with host file edits.
</blockquote>
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.
<blockquote type="cite">
Would this explain anything?
</blockquote>
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
</pre></blockquote></body></html>